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ABSTRACT 

Coocurrrat  eogtoeeriog  involves  the  integratkio  people,  tystemt  and  mfonnaticn  tnu?  a  r»pomh« 
^Bcieot  qfstem.  InU^tioo  of  computerized  tftteas  slkiws  additicHul  benefits:  auUHnsbc 
knoudedge  capture  during  development  and  fifet^e  maxufenient  of  a  product,  and  automatic 
eadtange  of  t^t  knowledge  among  diflEereiit  computer  qistema.  Critical  ei^leri  are  product  data 
standards  and  enterprise  intqpraiioo  fiaineworks.  A  pioneming  amauh  on  the  complex  technical 
challenges  is  amodated  with  the  emcrgmgBiternatiooal  Standard  for  the  Exchange  of  Product  Model 
Data  Surpassing  in  scope  previous  standards  efforts,  the  goal  is  a  complete,  unambiguous, 

computer-rmulable  th^mition  of  the  pfaysicai  and  fimctiooal  charamerimka  of  a  produa  throughout 
itsUfeqrde.  government  agencies,  induttrial  finas,  and  standards  orpmaattions  are  cooperatii^ 
itt  a  program.  Product  Data  Enhaafe  uri^;  STEP  (PDES),  to  devek^  and  implement  STEP  in  a 
shared>d8tabase  enviremment  PDES  wiO  lead  to  hifdwf.itd^rated  levels  of  automatkm  baaed  upcm 
information  standards  and  firameworics.  U,&  manufacturers  will  boiefit  from  coocurreotaxgineering 
without  sacrificing  the  historical  strei^ths  and  traditions  cd  individuality,  initiative,  and  inteUectuaJ 
piqperty  ri^ts.  Omeurrent  engineeritig.  throu(^  infOTtnation  tedux>iogy  and  standards,  represents 
the  power  of  a  new  industrial  revolutimi.  The  role  of  the  NIST  National  PDES  Tesdied,  tedinkai 
leadership  and  a  testii%*based  foundation  ftn  the  development  df  STEP,  is  described. 


KEY  WORDS 

Automated  manufacturing;  concurrent  design;  concurrent  migineering;  information  standards; 
manufacturing  staiKlards;  PDES;  product  dau  engmeerin^  product  data  sharing;  produa  data 
standards;  STBP 
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I.  INTRODUCTION 

Product  data  standards  will  rew^tiooEK  manu&cturing  and  enable  U5.  industry  to  build  on 
its  traditional  strengths  and  regain  ia  competitive  edge  for  the  twenty-&st  century.  Standards  will 
tmable  concurrent  engineering  to  be  uttiked  in  the  diverse,  dyrumic  and  heterogeneous  multi- 
entoprise  environment  that  traditional^  has  characterized  U5.  industry. 

Concurrent  engineering  provides  the  power  to  innovate,  design  and  produce  when  all  possible 
impacts  and  outcomes  can  be  ccHnidered  almost  immediately.  It  is  the  use,  in  all  phases  crif  a 
manufsctiffing  activity,  of  all  the  availabie  information  about  that  activity.  It  represents  the 
commonality  of  knowledge  applied  to  a  production  goaL 

Cemeurrent  engineering  can  stimulate  and  maintain  the  diverse  and  individuataUc  nature  of  the 
entrepreneurial  environment  by  expanding  access  to  knowledge.  It  forces  a  ^c^al  optimization 
among  all  of  the  prodtmt  life  cycle  processes  within  a  design  ami  production  system. 

However,  in  an  automated  environment,  concurrent  engineering  is  impossible  without  standards. 
That  is,  the  foil  automation  and  integration  of  industrial  processes  is  impossible  unless  standardued 
hardware  and  software,  especially  standardized  knowledge  and  knowMge  modeh,  exist  to  allow 
intercommunication  among  ail  types  of  computerued  systems.  The  significaiKe  and  potential  impact 
this  anmtion  are  the  subjects  of  this  document 
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la  priacqile,  ooocuneat  enfmeeru^;  doei  hoc  have  to  be  ao  autcMaated  procesa;  it  couki  be  people 
OKteracting  diiect^  with  othex^  pec^le.  In  practice,  in  today’s  manul^uriog  envitxMtstent,  the 
inoeMcd  ctxapleadty  products  and  ptoccttes  and  the  use  trf  ocnnputenaed  tyuem  piedudcs  sole 
reliaaoe  cm  people-topet^le  conrairrent  engtoeering.  The  approa^  to  coocutrast  oigineiimng  has 
to  be  thtixH^  the  automatic  aharit^  knowiedge  by  ccxoputeriaesd  iy«tc^  It  can  be  thought  of 
an  auttnnated  concurrent  rntgineoing^  or  oomputer-akied  ooocummt  eagbeering. 


hi  the  U5,,  the  imroductkm  of  amcurrcnt  engineenog  to  an  cnmrpriie,  or  to  a  group  of  connect 
eatmpriKi,  throi^  people-to-peopie  interactioiis  requires  usually  unacceptable  oilturai  chanipaL 
Because  it  emphasizes  teamwork  rather  than  oompetitioo,  people-to-pec^le  conounmat  en^neotag 
may  be  m  caaSkt  with  a  company’s  culture  (x  management  styk.  Or  it  may  mtmfme  with 
relationships  among  the  dkpartments  within  a  company  or  among  the  ccmipanies  within 
a  grmq>  of  ccMnpaiiies. 

Howevm,  introducing  ocmcurrent  engmeering  tbrtxigb  integrated  comfimta-  systons  doa  not  require 
cuHtaral  changes.  Even  while  the  integrated  computer  systems  are  sharing  infotmatkm,  people  in  the 
manufacturing  enviroiunent  have  the  choice  of  bow  they  respond  to  the  informatirm  presented  to 
them  automatically  thdr  computers.  They  do  have  to  alter  the  way  they  work  because  they  are 
ntiliring  greater  amounts  of  information;  however,  they  (to  not  have  to  alter  the  way  they  interact 
perscmally  with  tnher  pec^le.  Ic  this  manner,  concurrent  engineering  does  acA  require  cultural 
changes.  People  and  companies  can  interact  and  can  perform  their  activities  either  intiividually  (x 
coilectivety,  whatever  style  suits  them.  The  entrepreneurial  spirit  does  not  have  to  be  stifled  by 
business-imposed  interaettoos.  The  key  is  that  tbe  computer  systems  used  by  the  people  and 
companies  interact  effectively,  and  automatkaQy. 

Omcurcmit  engmeering  achieved  through  tbe  integratioo  of  computer  lystons  can  create  a 
cooperative  environment  within  a  company,  as  wdl  as  among  companies.  In  fset,  ’multi-enterprise 
concurrent  engineering"  can  result  in  bringing  together  indepeadently  innovative  companies  without 
any  kxs  of  iodependenoe.  This  will  provide  tbe  mechanism  for  the  U.S.  to  develop  its  own,  unique, 
U.S.  culture-ba^  approach  for  achieving  world-class  manufacturing 

If  the  approach  to  (xmeunent  engineering  is  through  automatioo,  coocurrent  oigineeriog  requires 
the  application  of  information  technology  to  CRmte  the  means  for  automated  systems  to 
communicate  aiKl  mteroperate.  For  example,  within  a  manufacturing  enterprise,  computer-aided 
design  systems  must  be  able  to  share  informaticHi  with  analysis  systems,  manufacturing  systems,  aito 
daitribution  systems.  Eventually,  concurrent  engmeering  can  be  applied  to  ail  business  systems,  not 
only  manufacturing  systems. 

Interconii«:ted  automated  business  systems  will  provide  managers,  engineers,  accountants,  marketing 
specialtsts,  distributors,  and  everyone  involved  in  a  business  enterprise  with  ail  tbe  information  they 
need  U)  carry  out  their  functioos.  This  includes  information  they  need  to  make  decisiom  as  well  as 
infiwmatton  about  Iktw  their  decaions  affect  the  dedstons  and  activities  of  everyone  else  in  the 
buriness.  Plans  and  actions  will  be  made  simultaneously,  without  the  delays  expertonced  in 
tradittonal  paper  communicatioos  and  face-to-face  meeting  as  prcsjects  progress  step-by-step  in 
linear  fashton. 

Even  suppliers,  parttwis,  atul  customers  can  be  linked  through  an  information  network.  In  this  way, 
multi-enterprise  corcurrent  engmeering  can  create  vertically  or  horizontally  integrated  manufactiuing 
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mtitk*  de  facto,  AhbcM|^  the  nq>ptias  would  not  be  cootrcdled  by  the  lyitaiif  int^peiour.  &»r 
example,  m  thqr  m%itt  be  in  a  vmtiaiUy  intepmied  entity.  nq>plkx  canjMuiies  and  s^tont  acMnnbly 
ctmipanies  might  coqiaatB  Ui  thmr  mutual  advantage  throt^  the  thaiing  ai  product  dau  and 
decition-ietotid  infonnatioa 


In  (Hir  increasingly  global  eooomny,  d^tal  informatioo  techncdogy  hm  t^aerged  »  a  critical 
detmmiiiant  oi  intematiQiial  compmitiveneis.  From  oomputcas  to  teleocmimunicaticxtt  to  miiitaiy 
^tons  to  consumer  ekctronics,  the  future  erf  a  nation's  eomomic  and  worldwide  influoice  wtU 
dqpeiKl  cm  its  excadkmoe  in  chfltal  infixrmatioo  tedmo  Just  as  the  imlustrial  tevoluticm  changed 
the  world  (xder,  the  inh^atkmrewrfutKm  will  toex  Just  as  steel,  ships,  and  ccmipuias  affected  the 
balance  of  ecxxxmiic  and  miiitaiy  powm,  infiormatkm  technology  will  toa  Cematrrent  engioeenng 
is  cme  of  the  applicatkms  of  toffumatioo  technology  that  wiB  provide  unique  eocmcmik:  cippcxtunitkau 

The  result  of  multi-enterprise  ocmeunent  engineering  is  m<»e  than  just  die  optimizatkm  erf  a  design 
and  pnxiuctkm^stem-it  is  a  broader  optiniizatkm  erf  an  industrial  system.  The  technicat  challenges 
are  numescnis  and  difficult  Equally  challenging  is  the  attainment  of  intematioDa]  consensus  on  the 
methexis  achieving  the  required  nctworidng  of  diverse  types  of  bunoess  systems.  Inteniatkmal 
consensus  <m  the  means  for  intq;ratiii^  automated  sjfstema-tbe  standards-is  emmtiat.  No  sin|^ 
company,  in  fact  no  single  ccnmtry,  bat  enou^  resources  to  develop  suitable  methods  applicable  to 
all  busineisea  in  an  countries.  Evm  if  h  were  to  happen  that  one  company  developed  an  intqpratkm 
method,  the  likelihood  erf  aco^tanoe  by  everyone  else  is  oegl^ie.  Qea^,  the  best  approKb  it 
through  consensus-based  intematkmal  standards. 

Yet  sometimes  standards  are  viewed  as  constraioers  erf  innovatkm  and  inhBriumicrf  new  technerfogiet. 
Fortunately,  standards  for  enterprise  int^ratiem  are  mterfoce  standards  or  "c^ien  lyuem  standards." 
Interface  standards  relate  to  interoperabStty,  uicludlog  data  exchange  and  intercommunicatiem, 
amcn^  different  hardware  and  software  eluents.  InterfiKe  standards  encourage  independent 
development  of  interc^ierabk:  products  because  they  specify  both  the  cJiaracteiiuics  of  critical 
Interfax  and  the  way  in  which  the  informatkm  transferred  across  the  interfaces  is  represented 
digitally. 

Such  standards  are  welcomed  by  manufacturen  because  they  lowmr  barriers  to  market  entry  and  they 
enlarge  me  market  From  the  customm's  view,  open  system  standards  lead  to  more  inrense 
ccmipetitkm,  a  hu^  number  erf  vmidon  fixmi  which  to  choose,  a  greater  variety  of  off-the-shelf 
solutkms  that  are  both  less  likely  to  become  obsolete  and  more  likely  to  be  easily  integrated  into 
existing  sqnttems,  modular  systems  that  can  be  configured  fw  improv^  performance  in  a  specific 
appticatkni,  aixi,  as  a  result  lower  prices.  Manufacturers  do  not  want  to  venture  down  proprietary 
patltt  with  the  risk  that  they  may  one  day  find  themselves  at  a  dead  end.  Everybody  wins. 

CoiKurrent  engineering,  based  upon  product  data  standards  and  enterprise  integration  firamework 
staixlards,  trufy  represents  a  new  hmn  of  concurrent  engineering  that  can  be  called  "multi-enterprhe 
cemeurrent  engineering.”  Multi-enterprise  concurrait  engmeming  extends  tiie  prindptes  of 
omeurrent  en^neming  to  our  U.S.  environment  It  can  be  defined  as  the  systematic  approach, 
across  industrial  miterpriies,  to  the  integrated  concurrent  design  of  products  and  their  related 
procenes  (sudi  as  manufacturing  and  support)  through  the  sharing  of  product  data. 

Achievmg  the  beneffts  of  concurrent  oigineering  (Section  11)  requires  an  understanding  of  the  unique 
role  (rf  the  design  process  in  the  life  qMe  of  a  product  (Section  m).  However,  concurrent 
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g^pwaatinf  aacoviipattes  next  tl»n  the  individtial  proceaae*  is  the  Ufe  cycle  a  product  It  ako 
inchidea  aodal  practioea  aad  rai^cxaa  ancMif  peofde  ami  tbdr  cxganuaitKm  that  are  iovolved  in  tboee 
hfis  cydb  prooeisea  Rxtunatefy,  it  can  be  tiiown  that  ccaicurKat  engiiiemf^  praetkea  implemented 
uiii^  integrated  automated  igiateau  a#  not  interfere  with  traditkmal  social  interagkmt  but  wiU 
greatly  mduuice  the  stmmgtha  <A  the  US.  style  oi  commerce  (Secskm  rv>  The  emeotial  ingredients 
fbf  ti^  to  happen  ate  the  technok^ies  a^  standank  that  wiU  allow  the  shari^  ci  informatkm 
ttBKmg  aU  (xmiputertzed  bunneas  syateraa.  An  unprecedented  efifort  by  a  variety  otganizatkms  to 
devek^  the  reqinted  tedhnologies  and  to  imptoemt  internationally  the  tequned  product  data 
ttandatds  is  undkoway.  STEP,  the  Standard  fisr  the  latdMnge  of  Product  Modd  Data,  k  the  focus 
dt  that  i^fart  ^ksetkm  V). 


n.  CONCURRENT  ENGINEERING  IS  TEAMWORK-IN- 
EFFECT 

Concurrent  engineering  k  a  process  that  invdves  the  intention  of  infixmatkm.  in  ptinetpie,  in  a 
concumrat  engineering  approach,  aU  the  avaUabk  infixmation  about  a  product  k  accotsibie  at  every 
stage  in  its  design,  manufacture,  suppext,  and  recovery  or  disposal,  as  Olustrated  to  Figure  1. 

Aconcurrent  migineering  approach  could  be  implemented  by  usembiing  a  team  of  (human)  eapexts, 
each  wfarxn  k  a  specialkt  reaponsUrle  for  cme  ex  more  sta^  of  the  produa’s  life  cycle.  The  team 
would  ceate  and  support  the  product  over  its  life.  Access  to  informatxxt  wrxild  be  aocompitsbed 
either  by  request  for  the  informatkm  by  the  expert  who  recofoiaes  the  need  for  it  (X  by  contributkm 
of  the  Mormation  by  the  eaqmrt  who  recognizes  its  tsyfolness  at  the  time.  The  human  team  k  the 
mechanism  fex  integradi^  the  product  iitformatioa.  Examples  of  product  infonnatioo  used  by 
experts  in  dififerrat  phases  o£  a  product's  life  cyde  are  shown  in  Figim  2. 

The  human  team  approach  works,  but  k  Umited  by  cultural  and  orguiizatkmal  practices  and  by  the 
amount  and  oompi^ty  of  the  inKxmatkxr.  An  altmnatrve  approach  that  has  wxie  of  these 
limitations  k  auttxnatkm  of  the  creatkm-UHlisposal  process  fix  a  product  In  thk  approach, 
ctmiputenzed  systems  access  the  tnfixmatkm  arid  eitbm  automatically  utilize  it  or  offer  it  to  the 
appropriate  human  specialkt  at  the  proper  time.  Therefore,  the  mechanism  for  integrating  the 
pr^uct  information  k  the  totality  of  interconnected,  infixmatkm-sharing  automated  systems.  Thk 
k  iHustrated  in  figure  3,  No  human  team  need  meet  or  interact  face-to-face.  The  spcxkdkts  couki 
be  seqrarated  both  physically  and  oi^;anizatioimIly. 

course,  human  specialtsts  must  sdll  play  a  rok.  They  create  designs,  make  value  judgements,  and 
make  dedkkxis  from  information  provided  by  the  automated  systems. 

Nevertheless,  concurrent  engineering  truly  represents  teamwork,  even  in  its  automated  embodiment, 
vriien  an  actual  team  of  human  experts  has  not  been  created.  Using  a  concurrent  engineering 
approach  made  possfole  by  integrated  auUnnated  systems,  product  expeiis  operate  as  they  would  in 
a  traditkxial  environment  Thk  k  because  they  (or  their  computers)  utilize  infixmatfon  foxn  and 
provide  information  to  each  other  as  needed. 
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Fig.  1.  A  "world  class”  product  requires  an  enterprue-wide  commitment  to  exccilencx.  Examples  of  various  life  cycle 
stages  of  a  complex  product-an  airliner-are  shown  schematkally. 
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Fig.  2.  Examples  of  knowledge  that  is  needed  by  the  specialists  involved  in  the  various  product  life  cycle  stages  arc 
illustrated.  The  sharing  of  the  product  knowledge  leads  to  concurrent  engiiK«ring. 
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A.  llw  McaodiBg  of  OMKUtTMt 


Coocurrent  en^neermg  is  an  old  concept  It  has  sometimes  been  called  concurrent  design, 
simultaneous  engineering,  and  ^tem  engineering.  Even  prior  to  these  labels,  m  earlier  times  when 
imlivkiual  craftspeophs  created  irulividual  objects,  they  took  into  account  such  factors  as  the 
properties  of  the  materials,  the  manufacturabOi^  of  the  parts,  and  the  function  and  utility  of  the 
reject  The  integration  of  the  product  information  occurred  within  the  mind  of  each  u^ivklual 
craftsperson.  The  end  result  was  a  complete  product,  ready  for  use  by  the  customer. 

When  factors  such  as  technology  led  to  more  complex  products  as  well  as  specialization  and 
compartmenialization  among  experts  and  workers,  the  integration  of  all  relevant  Monnation  was  no 
longer  spontaneous.  Increasing^,  the  tendency  was  that  the  Mormation  was  made  available 
se^pientialfy:  the  designer  designed,  then  the  manufacturer  manufactured,  and  so  forth. 

In  contrast,  concurrent  engineering  is  an  inherent^  parallel  process.  TM  integration  of  the 
information  required  for  all  phases  of  the  life  of  a  product  represses  serialism  and  promotes 
parallelism.  A  formal  definition  of  concurrent  engineering  emphasizes  this  idea  [1]: 

'Concurrent  engiimering  is  a  systematic  approach  to  the  integrated, 
concurrent  design  of  products  and  their  rented  processes,  including 
manufacture  and  support  This  approach  is  intended  to  cause  the 
developers,  firom  the  outset,  to  consider  all  elements  of  the  product 
life  cycle  from  conception  through  disposal,  including  quality,  cost, 
schedule,  and  user  requirements.” 

It  is  apparent  that  in  today’s  U.S.  manufacturing  euvircament  barriers  must  be  overcome  to  realize 
concurrent  engineering.  Therefore,  in  practice  concurrent  engineering  may  mean: 

•  Overcoming  resistance  to  teamwork;  that  is,  getting  designers, 

manufactiuing  engineers,  and  support  personnel  to  work  together, 

•  Overcoming  competitiveness  between  indivuluals. 

•  Retraining  the  educationally  specialized  in  newer  technologies, 

•  Modifying  management  styles  and  organizational  cultures,  and 

•  Developing  new  types  of  computer-based  tools. 

Tliese  are  input-  or  investment-oriented  issues.  Looking  instead  at  what  concurrent  engineering 
means  in  terms  of  outputs  or  benefits,  concurrent  engineering  may  mean: 

•  Lower  costs, 

•  Shorter  time-to-market,  and 

•  Greater  quality. 

These  results  will  affect  the  survival  of  a  company  or  the  success  of  an  industry  in  world  markets. 

While  ar^  and  aU  of  these  issu»  are  real  (and  are  e]q}lored  later  in  Section  IV),  the  single  most 
important  issue  regarding  concurrent  engineering  is  that  standards  for  all  types  of  enterprise 
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infcMrmatioo-especially  product  data  itaodarda-are  caaential  btxauie  ctmammi  is 

imptmibk  witium  mmdimtt. 

Even  if  a  muitkiiidplinary  team  of  engtoeeta  «>«£  Maembled  to  produce  a  product  m  wed  m  tbc 
procoiuita  aeceu&ry  U}  maintain  it  in  use,  it  is  impossible  such  a  temn  cmtld  qperatc  efl^caiveiy 
without  the  ability  of  the  automated  to  communicate  and  share  tnfcxmatkm  about  aU  plMwot 

of  the  produa’s  existeace.  In  today's  manufacturing  arviroomeot,  ocmcurteat  et^ncemg  mcam 
integralmi  infonaatioo  systems-and  that  means  product  data  uandards  are  needed. 


B.  The  Need  tor  Coswastmd  Engl—trtaf 

G}mpetitn«  success  depends  on  shortening  the  time  between  omceptioa  and  miroducuoc  of  new 
technologies  and  products  into  the  marketplace.  To  meet  the  need  to  minimua:  umc  to-markei. 
computer-aided  tools  are  used  to  move  the  product  from  ooocepi  through  tksign.  ptxMotype. 
manu&cture,  test,  and  inttxxluctioo  into  (he  maitetplaoe  (from  coocept  to  oomumptton). 

Even  as  pressure  is  applied  to  decrease  product  devclq;Hneat  tune,  the  diversity  a(  actmiics  and 
expertise  required  to  bring  a  product  to  fruition  are  increi^nf  dramaiicaUy.  Tha  a  because  tn 
addition  to  meeting  functional  oeeda,  the  product  must  meet  etsergy,  etmroamcnul  health  and 
safety,  and  other  requuements.  These  oon-treditiocial  requirements  are  beoemsing  more  demandmg 
on  fflanufKXuren  as  the  lophisticatioo  of  our  culture  advances  and  as  oitf  knowledge  of  the  impacts 
of  human  activities  on  the  ^obal  envirtxuaent  espanda 

Because  cd  the  need  to  minimiae  the  time  from  conoeptioo  of  a  product  to  its  delivery  to  a  customer, 
and  because  of  the  amount  and  variety  of  ii^ormatioa  needed  by  manufacturers,  oompuien  are 
essential  in  manufacturing.  They  are  used  to  (kstgo  products,  for  their  manuCaaure,  ocmtrol 
the  equipment  that  produces  them,  cemtroi  the  equipment  that  tests  them,  manajp;  their  distrfoution. 
and  help  support  their  operatioa,  repair  and  mamfcnancr  Furthermore,  because  most 
manufaarturen  of  complex  products,  fw  example,  vehicles  and  oomputen  themselves.  maoufK:ture 
only  a  fractioo  of  the  pans  in  these  products,  there  are  needs  rdatmg  to  activities  such  as  inventory 
control,  scheduling,  and  ordering,  as  well  as  the  coordination  of  sil  the  manufacturing  activities 
the  supplier  companies.  But  the  needs  can  be  only  partially  met.  and  the  advanuges  of  cuing 
computers  only  partially  achieved,  unless  the  computers  can  interoperate-that  is.  share  infemnation- 
so  that  they  can  perfonn  their  tasks  tn  parallel  In  this  manner  computms  and  integration  naturally 
point  to-€ven  demand-concurrent  engineerittg. 


C  Tlw  Bos^im  of  OMKUiTcat  Ea^acsrlag 

Concurrent  engineering  can  sbortoi  the  time  required  befem;  a  product  s  marketed.  It  can  improve 
productivi^,  profitability  and  competitiveneia.  It  can  lower  coats,  reduce  waste,  improve  quality,  ami 
improve  elEk^ency  in  all  phases  of  the  life  of  a  product  [1].  It  can  allow  supplfen  ami  vendors  to 
coordinate  their  operatfom.  It  can  enable  manufacturers  to  cooperate  in  consortta  in  precompetitire 
pra^rets.  SvtCh  co^tnated  operations  increase  the  resources,  lower  the  cost  and  reduce  the  risk  for 
emdi  individual  participant  This  may  allow  the  participants  as  a  group  to  be  more  innovative  atKi 
risk-taking  to  produce  more  competitive  products.  In  today's  aggressively  competitive  world  market 
concurrent  engineering  may  mean  the  difference  between  failure  and  succos  of  an  industry. 
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The  tt»«ioaiic  benefit  of  nicceti  (that  it,  at  least  survival)  compan»l  to  failure  is  obvious.  But  there 
are  other  benefits  related  to  overcoming  the  banien; 


TeembmU^  Cbm:urient  engmeeiing  integrates,  tbroo^  the  shaimg  ctf  inficMmat^ 
people  involved  in  a  manufhc^oing  activity.  They  beocmtc  a  team  tfarou^  their  automated 
i^steiiis.  The  intaracticHU  can  be  optimised,  even  though  they  may  not  include  face-to-faoe 
interactions,  and  the  individual  tmun  memben  can  perform  to  the  limits  of  their  capabilities 
antbout  chai^iog  their  peiscmal  or  interpersonal  s^ks. 

Worken'  Career  Grvmh.  New  forms  of  workplace  cngantzackm  in  modem  manufacturing 
facilities  gives  wtnkms  more  responnbility  {2].  Inaeasir^,  they  must  use  Judgement  and 
makedecisioas.  Ck»curreot«igineoing^aGceieramthktieDd,anditwflltt^pcHrtwmtefs 
with  the  Mormatkm  they  need. 

Mamgemeni  The  concurrent  engineering  environment  will  give  managers  the  id>ility  to 
oversee  aQ  activities  thiou|^]out  their  oiieipfise-witbout  any  additkmal  bureaucracy. 
Managers  win  be  able  to  have  the  information  they  need,  u  it  is  created,  to  anticipate,  pla^ 
and  act  quickly. 

Competition  and  Choke.  It  takes  years  for  companies  in  an  industry  to  recognize  aU  of  the 
different  specialty  niches  fm  systems  and  to  dev<^  viable  products.  Fot  example,  althou^ 
the  basic  interface  spedfications  for  peiscmal  computers  were  established  in  the  early  1960‘s, 
new  typeset  hardware  and  software  products  are  stilibmng  defined  txxlay.  In  the  same  way, 
the  integrated  concurrent  engineering  environment  will  provide  opj^unities  for  new 
products  that  cannot  be  predicted  now.  The  enablmg  vehicles  ere  standards.  In  addition, 
»noe  no  one  manufacturer  offen  computers  that  wiU  ckaign,  manufsoure,  and  support  a 
product,  interface  standards  are  eamnUaL 

Additional  thoughts  on  the  benefits  of  conewrent  engineering  as  both  a  method  and  an  enviitmment 
are  discussed  in  Section  IV.  In  the  next  section,  an  important  reason  why  concurrent  engineering 
can  provide  considerabie  benefits  is  discussed.  The  reason  is  that  concurrent  engineering  affects 
(ksiga  dedsioas.  Cemeurrent  engineering,  based  upon  intt^ted  automated  systems,  allows 
spedalixed  enginem  firmn  all  phases  of  a  product's  life  cycle  to  participate  in  design  dectsiom,  aiKl 
tins  has  a  major  impact  on  the  cost  the  product  [3]. 


m.  DESIGN  IS  THE  CRITICAL  AREN  A  FOR  CONCURRENT  ENGINEERING 

If  manufacturing  is  the  use  of  energy  to  convert  materiah  and  components  into  saleable  products, 
thmi  design  is  tlm  use  cf  kiKTwIedge  to  convert  information  and  requirements  into  fumkionaliQr. 
Design  includes  both  derign  of  a  product  as  well  as  design  of  the  manufacturing  systems  and 
processes  to  produce  the  product  Design  dedsions  affect  all  aspects  of  the  life  of  a  product 
including  production  cost  and  other  diaracteristics  of  the  product’s  manufacture,  marketing, 
maintenance,  repair,  and  di^xMsL  A  "good*  product  design  addresses  the  coocerm  of  each  of  these 
characteristks  as  well  as  file  quality,  cost  ami  functionality  of  the  product  to  the  tner.  Examples  of 
the  kinds  ctf  information  needed  by  a  designer  are  listed  in  Figure  4.  Worid-class  products,  piquets 
that  are  competitive  in  timeliness,  performance,  coat  and  quality,  result  from  good  design. 
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Hie  designer  especially  has  a  need  for  knowledge  about  the  prc^ierties  of  a  product  during  its  Ufo  cycle. 


The  tenn  *ooiicurr«Dt  design*  refm  to  the  'cooidisated  design  of  products  and  processes  so  that 
dEEixAive  and  (^Ekaent  manufscturing  wQ!  be  possibie"  [4].  Comautent  des%D  » tbcrt^mc  consistent 
with  intuitive  omcepts  of  *good*  ctesign.  (Altbot^  go^  engineering  design  has  been  ntcue  formally 
described  »  a  process  that  auures  "pr^ucts  ate  designed  and  manufj^ured  with  ‘deugned  in* 
instead  of  ’tested  in’  reliability  and  maintainrinlity*  [S].)  The  point  is  that  concurrent  design  is  the 
oofy  dei%B  appioadi  that  wotis  in  a  ccmcurRmt  eagmeering  approach. 


A.  llwUniqBMMssserDcaign  iathsLifcC^yckofa  Prodact 

jj^xsflily  because  it  includes  tire  initial  stages  of  the  (kvek^ment  of  a  product,  and  certainly  because 
it  detennines  the  nature  ol  the  future  attributes  of  a  product,  the  process  of  design  exerts  tire  most 
control  over  a  product’s  life  cycle.  Fot  example,  ab<Mt  60%  of  a  product’s  cost  is  fixed  very  eariy 
in  the  process  of  desigt^  overall,  the  design  process  may  fix  as  much  as  almost  90%  of  the  total  cost 
of  a  product  [6].  This  means  that  production  and  production  managexnmit  decisions  affect  oviy 
about  20%  to  30%  of  the  total  costs.  This  is  shown  in  Figure  S.  Despite  its  impwtance,  the  design 
process  is  often  inefficient,  d^acbed  from  the  productkm  process,  undocumented  in  umns  of  the 
rationale  fr»  design  dedsioos,  and  production-facOity  depe^nt 

A  fundamental  problem  with  devek^ing  effective  dei^  environments  and  rquesenting  design  intent 
has  been  a  lack  of  a  conceptual  mottel  of  the  design  process.  Without  a  modd  frnr  the  various  fscets 
of  the  design  process,  computer-based  design  tools  will  rmnain  customized  and  relatively  isolated, 
interacting  only  at  low  lerels.  In  this  situation,  unique  solutkms  and  individualized  integration 
schemes  substitute  for  an  appropriate  ardiitecture  fr»  the  use  of  concurrent  engineering  in  design. 

The  design  process  can  be  divided  into  conceptual  design,  detailed  design,  and  manufrcturing 
system/process  design.  Early  in  the  ccmceptual  design  phase,  just  vtiren  time  is  the  most  flexibility, 
most  of  the  total  costs  of  tire  product  are  committed. 


1.  Ccmceptual  Design 

The  Goaoq>tual  design  phase  is  wfami  the  concept  for  the  product,  including  sub-assemblies  and 
cranponents,  a  develops  The  general  shape  of  the  produa  is  known,  but  detailed  geometrre 
infbrmation  is  not  yet  available.  T^  output  conceptual  design  activities  contains  assumptions, 
constraints,  conditkms,  and  other  infcnmation  related  to  a  product  that  must  be  used  by  downstream 
operations  to  produce  and  support  the  product 

Important  decisions  are  made  during  conceptual  design  that  affect  the  nature  of  a  prcxluct  sireh  as 
complexity  mod  maintainability.  The  computer-aided  ei^;iiwaring  (CAE)  tools  required  to  involve 
dca%n  in  the  overall  concurrent  engineering  approach  should  be  integrated  and  interfaced  and 
should  be  c^ble  of  representing  functkmal  ir^ormation  about  the  product  The  designer  ireeds 
such  information  ea^  in  the  design  prcreess,  and  in  a  form  that  is  readify  accesrible  to  the  design 
tcxib  being  used. 

Computer-aided  engineerii^  tools  allow  the  designer  to  model  the  qualitative  and  functional 
pmformanoe  of  the  product  CAE  tools  indude  took  for  simulatwn  of  operations,  structural  and 
medianiaU  analysis  sudi  as  finite  etement  and  boundary  element  analyss,  flukl  flow  and  thermal 
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Fig.  5.  The  cumulalhcpefcait  of  the  total  oort,  or  KfeqMecott,  of  •  product  iitlioiraM»fuiicliooo£ihctugei  of  ihe 

product’*  life.  Early  desim  dediioiia  detomuie  aroat  of  the  uhimate  coid.  (Adapted  Ctoib  (6}.) 


anafysis,  aoiid  and  sui&ce  modeliflt  and  a  variety  of  cKfaer  ^>eciatiaed  evaluatk^n  of  the  potential 
product  Such  anatyies  to  thstennine  perfonnuxe  charaoteriidia  axe  atecuted  usually  on  an 
idealised  femnetty.  Unfortunately,  most  of  today’s  CAE  tools  have  their  own  propxietaxy  data 
structures  and  interfaces.  The  data  are  oot  available  to  <xher  cxnnputer  programs  a^  axe  mteifaced 
only  to  the  human  user. 

In  addition  to  iacldiif  the  abOity  to  exchange  informatkm,  most  of  today’s  CAE  tooh  aho  lack  the 
ability  to  represent  ncm-gecnnctric  functkmal  informatkm  about  the  product  It  is  important  to  know, 
f<«  exampl^  whether  a  product  must  be  ncm^XMoductive  or  ctxxosioo  xenMant  and  whether  it  wiU 
be  used  in  cxnyunctkm  with  or  interact  with  some  other  device.  To  allow  for  automated  or 
aHnputer>sem^le  concurrent  ei^ineering.  CAE  tods  must  be  able  to  capture  foxKtkm  information 
and  to  represmit  ptyucal  otqects  better  than  is  possfole  today. 


2.  Detailed  Design 

During  the  detailed  design  phase  the  product  k  ^)edfied  completely  and  uxuunbiguousiy.  The 
geometry  and  topdogy,  the  dimensions  aiul  tolerani^  and  any  features  needed  as  a  result  of  the 
analyses  performed  during  the  conceptual  design  phase  are  spedEed  in  detail 

In  addition  to  speeding  the  product  in  detaO,  assurance  must  be  developed  that  aU  features  of  the 
product  design  are  consistent  snth  priorities  and  considmtkms  for  downstream  life  cycle  stages.  For 
example,  it  must  be  (tetermined  that  toieraiKes  are  neither  too  loose  to  meet  functionality  needs  nor 
too  restrictive  for  manufacturability  and  low  cost  Tolerance  decisions  reflect  the  capability  of 
available  manufecturing  equipment;  dther  the  designs  modifies  the  design  to  accommodate 
equipmoit-dictated  toleranoes  or  dei^ms-in  tighter  tolerances  that  necessitate  spedalued  equipment 
To  create  a  design  having  predictable  product  funefionaiity,  manufecturabOity  axxl  cost  the  designer 
must  know  the  effects  <d  alternative  design  dedsions. 

The  designer  also  needs  infimmatkm  about  the  importance  of  the  product  attifoutes  as  they  relate 
to  the  processes  the  product  will  encounter  in  its  Ufe  to  make  knowledgeable  design  decisions. 
Questkms  such  as,  I*  poformanoe  m<ne  important  than  maintainability?,*  Ts  ease  of  assembly  more 
important  than  durabilxty?,*  and  *How  do  these  dtaractmtics  relate  to  cost?”  must  be  conddered 
and  must  have  answers  detailed  design  is  to  be  omnpleted  successfully. 

In  a  concurrent  engitteering  environment,  the  dedgn  tools  have  access  to  informatfon  about 
downstream  life  tyde  Goauderations,  induding  costs.  Furthermore,  the  tools  are  able  to  measure 
and  eaqpress  in  a  quantifiable  manner  the  results  of  aoalyies  ctf  the  impact  of  detailed  (fesign 
(fasdmxB  on  downstream  stages  of  the  life  tyde.  Obvious^,  the  CAE  tools  must  be  interfiKxd  to 
other  automated  tystems  if  tlxy  are  to  accomplish  such  ta^ 


3.  Manufacturing  System  and  Manufacturing  Process  Dedgn 

The  des^  of  the  manufecturing  tystems  and  processes  that  will  be  used  to  produce  the  product 
invetyes  detailed  kitowiedge  of  a  different  type  than  may  have  been  needed  earlier  in  the  design 
process.  Information  sudi  as  the  number  of  devices  to  be  produced,  the  batch  size,  the  process 
capablhties,  the  availability  of  materials,  aixl  other  infenmation  about  manufacturing  operatioia  and 
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equqnneiit  was  needed  earlier,  but  typically  to  avoid  a  des^  that  violated  oartaio  practtcal 
limitatioiis  tm  its  production.  At  this  point,  this  kind  of  infc^mation  is  needed  to  detennine  the 
actual  sequence  of  manufacture  and  the  fjadlitiet  tad  production  equipment  required. 

The  CAE  tools  used  at  this  point  are  also  different  than  those  used  earlier  in  the  design  process,  but 
they  share  the  same  need  for  integration  and  interfacing.  Software  for  process  planning,  modeling 
of  the  actual  manufacturing  processes,  programming  and  controlling  the  pr^uctfon  machic»s, 
fixturing  the  machines,  and  other  production  operatioos  must  have  access  to  product  design 
information. 

It  is  easy  to  see  how  tderanoe  information  would  be  important  because  it  relates  to  the  production 
processes  and  thdr  capabilities  for  predsioo.  What  is  less  easy  to  understand  »  Ikjw  design  intent 
informatfon  is  critical  for  concurrent  engineering.  This  is  considered  in  the  next  sectioo. 


B.  IV  Rqiieaaitetkm  of  Dcsiga  Intoit 

Solid  modeling  systems  improved  the  design  process  when  th^  replaced  "wireframe*  drawings.  Solid 
modeling  systems  can  be  ined  to  represent  an  objed  being  de«gi^  accurately  and  unambiguously. 
Recentfy,  solid  modeling  systems  have  been  used  to  gcmerate  finite  element  meshes  and  to  generate 
tool  pa^  few  machining.  However,  solid  models  still  do  not  help  in  aU  stages  o(  the  product  life 
cycle.  Th^  cmly  help  to  provide  more  complete  gecwnetric  information.  The  goal  for  coixrunent 
engineering  is  product  models  that  include  not  onfy  dimensions  and  tolerances,  as  well  as  other 
feature  infewmatioa,  but  also  information  about  the  decision-making  process  that  led  to  a  produa 
demgn. 

To  maximize  the  benefits  of  concurrent  engineming,  the  various  product  life  cycle  systems  must  be 
ifole  to  determine  how,  few  example,  the  diupe  or  dimensions  were  derived  and  why  the  part  mtwt 
be  newt-conductive.  Unless  sudi  design-intent  information  is  available,  it  is  difficult  to  minimize  the 
risk  of  making  modificatkms  and  improvements  to  products  and  manufacturing  and  repair  processes. 

New  sc^tware  tools  and  models  are  needed  to  measure  such  properties  as  design  "goodness;” 
manufaaurabQity;  product  and  process  performance;  product  and  process  costs;  impacts  of  cbac^ 
fnxn  one  alternative  tfosign  to  another;  and  manufacturing  configuration.  The  following  are  some 
examples  of  needed  design  toots  and  models  [1],  [7]: 

Process  modets  for  various  manufacturing  processes  such  as  metal  cutting  forming  injeaion 
molding  and  casting  The  models  can  be  used  to  alter  product  geometry  or  process 
parameters  through  various  engineering,  geometric,  statistical,  awl  scientific  analyses.  TV 
models  can  provkle  a  measurement  (such  as  tolerances,  material  integrity,  strength,  and 
surface  finish)  few  projecting  process  performance  (such  as  sp^ds,  temperatures,  and 
ptectrion). 

Assembly  and  cost  modeb  to  provide  the  desiffter  with  cost  prediction  estimates  and  deagn 
opdons  for  more  eanfy  assembled  products.  Geometric  models  of  position  and  path  for 
product  handling  are  also  useful 
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MamtfacQmng  syaem  models  to  measure  the  capacity  cfsyaans.  The  integration  of  capacity 
and  capability  modeia  in  muiufacttiring  allowa  the  designer  to  simulate  ami  analyze  the 
manufacturing  processes,  the  process  techncdogies,  and  the  derign  of  sutistkal  quality  ccrntroi 
methods. 

Factoiy  engineering  modeb  to  pnmde  the  date  remand  to  conpffin  new  faaories.  Thesetools 
can  be  used  to  show  how  a  dedsitm  to  unprove  cme  process  in  the  factcHy  mi^t  result  in 
rifflultanecms  changes  in  the  data  maintained  in  several  associated  applkatkms.  Some 
changes  which  m^t  occur  autonatically  include  revisioos  to  plant  laycmt  drawings,  utility 
requirements,  simulation  models,  oost/payback  projectiom,  ai^  procurement  spedficatkm 
documents  for  the  proposed  system. 

Future  systems  will  be  *intell^ent  machines*  that  receive  product  descriptioos  and  autennatKally 
interpret  them  and  perform  the  appropriate  machine  q}mratkms  to  achieve  the  desired  product 
geometry,  tolerances,  and  material  spedficatkms.  The  keys  are  the  integration  of  the  design 
databtoe  into  the  manufacturing  facility  and  the  integration  methods  for  translatir^  design 
descriptions  into  manufacturing  process  and  ctmtrol  programs. 

The  process  of  design,  as  well  as  manufacturing  generally,  will  be  improved  by  the  development  of 
standard  ways  for  representing  design  intent.  Softwue  tools  need  to  include  a  better 
understanding  of  the  design  process.  The  goal  must  be  the  inclusion  of  product  data  models  that 
incorporate  design  intent  ^ormatkm.  Onfy  with  a  standard  representation  fw  such  information  can 
the  output  of  des^  systems  be  used  by  tte  variety  of  other  automated  ^tems  resprmsibie  for  a 
product  during  its  life. 

It  should  be  dear  that  design  is  a  process  that  involves  a  series  of  activities.  During  the  derign 
process,  a  large  problem  is  deomipoaed  into  a  aeries  of  smaller  problems,  partial  solutions  are 
proposed,  and,  throi^  feedback  arid  the  resolution  of  constraints  or  tradeoff,  partial  solutions  are 
r^ned  until  an  overall  solution  is  reached. 

Present  computerized  aids  merely  help  speed  up  the  design  process  by  performing  qtikkly  Urn 
computaticms  needed  for  the  par^  solutions.  To  achieve  a  ooncurrmit  engineering  environment, 
a  fnmewc^  based  upon  a  mr^l  of  the  derign  process  and  appropriate  interfooe  and  product  data 
standards  is  required  for  the  integration  of  oomputo’-baaed  took  One  approach  is  to  view  the 
ormcurrmit  engineering  environment  as  a  Targentate  machine*  within  which  changes  in  the  state  of 
the  system  can  occur  in  predetermined  ways  [8]. 


IV.  CULTURE  AND  CONCURRENT  ENGINEERING  CAN  BE  COMPATIBLE 

Our  current  informatkm-based  society  [9]  seems  to  be  characterized  by  the  computerization  of 
everythir^  Earfy  in  this  poiod,  some  people  feared  that  computerization  was  equal  to 
dehumanizatkwL  Howevmr,  it  is  now  clear  that  it  is  the  way  cmnputers  and  digital  systems  are 
implemented  that  can  eithm  limit  or  extend  human  interaction  and  control  or  that  can  eitimr 
diminish  our  rights  or  endow  us  with  additional  heedoms. 
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Computers  seam  to  be  the  most  vntbk;  tigs  that  as  the  world  is  changtng,  cultural  and  tr^itiooal 
values  are  ccmiii^;  into  conflkA  with  technology.  Yet  there  is  eviden<%  that  omiputars  can  be  tned 
to  preserve  or  even  restore  traditional  approaches-at  least  at  the  human-machine  interface.  In  a 
fundamental  sense,  the  term  *ttter  friendly”  implies  a  recognition  of  and  deference  to  human  ways 
of  dning  things.  The  concept  of  "artificial  intelligeiKe”  omnotes  an  imitation  dT  the  human  mind’s 
ability  to  process  infcmnation.  These  are  examples  of  computers  helping  to  extend  our  behavur  and 
j^ilitks. 

The  relevant  questkm  »:  ”Does  concurrent  engineering  rq)resent  an  attadc  on  human  cultural 
values~such  as  creativity,  individualism,  and  pride-or  does  concurrent  engineering  allow  m  to  exteiKl 
our  abilities  and  (k>  more  of  what  we  did  b^oie,  in  the  way  we  do  it  best?” 

The  answmr  is  that  concurrent  engineering  is  in  harmony  with  us  as  humans  and  with  our  culture. 
Furthermore,  concurrent  engineering  may  be  the  only  way  to  preserve  our  style  of  doing  business 
in  the  U.S. 


A.  The  Rdsitioaship  BctwcM  Coacurcat  Engineertog  and  CompctUlvcMM 

The  U.S.  loss  of  competitiveoess,  shrinking  markets,  and  trade  deficits  are  symptoms  that  something 
new  is  genng  on  in  the  test  of  the  woricL  There  can  be  little  doubt  that  today  the  U.S.  is  losing  world 
market  ^lare  and  technological  kadership  in  most  of  the  lechncdogies  impcirtant  to  maintaining  our 
standard  of  living  [10].  According  to  a  recent  government  report  on  electronics,  a  major  growth  area 
in  the  U.S.  econenny  in  terms  of  mnploymmit,  output,  exports,  and  innovation  and  abo  vital  to 
natkmal  defense  and  security,  U.S.  leadership  is  under  serious  challenge  and  may  soon  be  eclipsed 

m 

Another  government  report  begins  a  summary  in  chapter  one  with  the  declaration:  "American 
manufacturii^  has  never  been  in  more  trouble  than  it  is  now”  [12].  According  to  this  report, 
manufacturing  is  weak  because  its  technology  is  weaL  And  unless  thb  weakness  is  cured,  the  U.S. 
will  not  be  able  to  ei^  rittng  livmg  standards  and  the  continued  creation  of  jobs  at  the  same  rate 
as  in  the  past  This  indudes  not  only  jobs  created  in  the  manufacturing  sector,  but  also  indirectly 
in  the  service  sector.  Manufacturing  teduxriogy  is  identified  as  the  key  to  national  competitive 
success. 

There  can  be  little  doubt  that  in  today’s  ecxmomk  climate,  and  for  the  foreseeable  future,  indiatries 
must  compete  in  world  maricets.  Among  industrialized  natioos,  int^national  competition  is 
increaHng  Yet,  as  evidenced  by  the  trade  deficit,  many  U.S.  industries  are  not  competing 
successfulfy. 


A  number  of  factors  are  cited  that  contribute  to  the  current  difQctiltks  of  U.S.  manufacturers  in 
^(4>al  maricets.  The  factors  often  include  federal  budget  deficits,  low  personal  savings  rates,  tlM  high 
cost  of  capital,  the  low  "patience  of  capital,"  the  weak  dollar,  short-term  profit  goals  of  rorporate 
managers,  short-term  pr^t  goals  of  investors,  lack  a  trained  workforce,  lack  of  access  to  foreign 
markets,  "dumpingf  ^  foreign  companies,  product  liability  and  Utiption,  inadequate  foreign 
proteetkm  df  intellectual  property  ri^ts,  federal  regulatory  restrrctiom,  poor  management-labor 
relations,  foreign  manufaauter-supplier  relationships,  antitrust  laws,...  Seldom,  if  ever,  do  the 
reasems  given  for  U.S.  poor  competitiveness  include  either  techiK>k)gy  or  standards  issues.  This  may 


19 


be  because  tbe  role  of  and  its  relationship  to  ecoTOoiic  factors  may  not  be  well 

understood.  Technology  is  sotnetimes  viewed  as  only  tbe  oteatkm  of  new  products  r8tlM»r  than  tlu; 
improvement  cht  tevoiutionaty  changing  o£  easting  manu&cturing  practioes.  As  mentioned  in  tlu; 
introduc^km,  standards  are  sometimes  viewed  as  mhibiting  change  rather  than  enabling  or  facilitating 
innovatkm  and  ccmipetition. 

Techncdogy  can  make  a  diffenaioe  when  it  provides  tbe  means  to  build  a  new  national  economic 
strength  or  to  build  on  an  easting  strength.  In  these  ways  technology  can  provide  tbe  means  to 
overcome  ncm-technical  barriers  and  to  produce  a  new  basis  for  competitiveness.  Completely  new 
technologies  can  evmi  char^  the  significance  of  the  ocm-technical  barrien,  making  some  of  them 
incemsequentiaL  Concurrent  engineering  based  oa  inregrated  autcanated  systems  may  be  able  to  db 
both. 

Actually,  coiKmnent  engmeering  has  already  been  shown  to  be  able  to  contribute  to  cennpetitiveness. 
A  Harvard  Business  School  stuefy  ihowed  cemeurrent  engineering  to  be  responsible  for  a  30% 
deoease  in  the  time-to-market  for  a  new  car  in  the  Japanese  automotive  indu^  (12],  (13).  Even 
in  the  U.S.,  in  a  study  of  six  defense  contractors,  concurrent  engineering  has  already  been  stown  to 
reduce  costs  30%  to  60%,  to  reduce  development  time  35%  to  60%,  to  reduce  defects  by  30%  to 
80%,  and  to  reduce  scrap  and  rework  by  58%  to  75%  [1].  However,  concurrent  engineering  ak>i^ 
with  integrated  ccmiputerized  ^sterns  appropriate  standards,  can  make  even  more  significant 
improvements. 


B.  The  Rdatiimship  Betwcesi  Conosmnt  EaglMcrlBg  Praetkas 
and  AlHanew  Aasong  Bnrinswss 

Manufacturers  are  linked  in  a  chain,  scmietimes  called  a  *food  chain,*  to  their  materials  and  parts 
supphen  and  to  their  customers.  It  wmild  seem  that  dose  links  and  stable  relationships  would  be 
advantageous. 

In  1968,  a  deteriorating  trade  balance  between  tbe  US.  and  Japan  reached  a  deficit  of  $6  billion. 
In  1969,  for  the  first  time,  tbe  US.  was  a  net  importer  computers.  In  1990,  abo  for  tbe  first  time, 
tbe  omiputer  systems  industry  had  a  aero  trade  balance.  One  important  reason  for  these  trends  may 
be  cultural  Tbe  perception  is  tlmt  while  US.  industry  is  considered  to  have  better  design  skills,  it 
does  not  have  the  business  partnerships  and  long-term  strategies  for  commercial  sucoem.  The 
Japanese,  who  lead  in  rapid  and  integrated  ”derign  fcH*  manufacturability”  aiKl  in  flexible 
manufacturing  have  strong  and  stable  business  partnerships  as  well  as  long-term  strategies. 

It  has  been  argued  that  the  advantages  of  Japanese  companies  in  world  markets  are  due  primarily 
to  thdr  dtvmrified,  vertically  integrated  structure  and  their  long-term  partnerships  in  financial- 
industrial  groups  called  *keiretsu*  [14].  Typically,  a  miqor  bank  is  one  member  of  a  keiretsu.  Thb 
is  impevtant  tecause  today  the  size  tte  investment  necessary  to  develop  a  imw  technology  h 
predubitive  to  most  omipanies.  The  ability  of  a  compaity  to  develop  a  technok^  and  quickly  bring 
to  market  a  product  that  utilizes  that  technology  is  an  obvious  ad^tage.  This  can  happen  when 
a  partnm  compaity  with  strong  oemsumer  product  development  sldOs  and  effective  marketing 
nedworia  devel^  the  product  even  as  the  technology  is  being  developed.  In  a  sense,  this  is  multi¬ 
enterprise  cemeurrent  engneering 
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Yet  given  the  evidence,  U.S.  iiKlustiy  has  been  slow  to  fonn  cooperative  reiatiooshi{».  Although 
mrae  companies  are  fonning  comoitia,  especially  for  joint  research  aial  development  in 
piecompetitive  technologies,  and  mcmB  companies  are  cultivating  closer  relationshi[M  with  their 
suppliei^  there  is  still  rewtance  to  budness  alliances  in  U.S.  industry.  This  h  true  even  t]K>ugb  the 
inUi^retatkm  of  anti-trust  regulations  is  gradually  weakening  and  federal  funds  are  becomii^ 
avaiiad)le  f(»  consortia  in  gerreric  and  precompetitive  technok^es. 

The  indivklualistic  entrepreneurial  spirit  helped  bring  us  to  where  we  are  today.  But  unless 
something  changes,  that  same  characteristic  wOl  prevent  the  U.S.  from  rerersing  its  deciirm  in 
(XMnpetitiveness.  This  is  because  in  a  woiid  "where  R4tD  and  commerdalization  costs  can  exceed 
$1  billion  for  a  single  technology,  small  companies  woridiig  independently  cannot  compete,  pnbe 
firagmaitatmn  of  U.S.  industry  into  small  anBpanies]..4pteads  R&D  funds  thinly,  skrws  techiK}logy 
diSiision,  aiKi  diflittes  manuf^uring  and  mariceting  power”  [15].  Yet  U.S.  technok^  companies 
do  not  make  the  strategic  partnerships  that  Japanese  companies  do  and,  if  the  current  tnuie,  market 
share,  aixi  direct  investment  (Japanese  companies  buying  high  techix>k>gy  U.S.  companies)  sutistics 
continue,  small  innovative  U.S.  technology  companies  may  not  be  able  to  survive. 

The  behavior  of  U.S.  companies  reflects  their  cultural  envinmment  "Rugged  individualam"  h  a 
desirable  charact^tk.  Strengths  include  creativity,  irmovation,  and  indtvkiualism,  even-pediaps 
espedalfy-in  commerce.  Competition  has  been  a  primary  motivator  and  strength  of  our  ^tem;  but 
it  does  not  coexist  well  with  the  notkin  of  entreprtmeursworidng  together.  The  "not  invented  here” 
syndrmne  and  the  stereotypical  "throw  it  over  the  wall"  s^  among  departments  within  companies 
is  qrmptomatic  of  cultural  values.  In  additkm,  the  tenden^  toward  an  adversarial  relationship  can 
divide  management  and  labor. 

How  can  all  this  be  reconciled  with  the  need  to  cooperate  to  form  large,  internationally  competitive 
business  structures?  How  can  it  possibly  svqppcnt  concurrent  engineering? 

The  answer  is  that  the  creation  of  an  automated  intenxmnected  computer  oivironment  can  fiee 
people  and  companies  to  operate  howevm  they  please.  If  infbnnation  can  be  shared  automatically 
and  the  computer  systems  people  use  to  do  tb^  wmk  can  interact  and  the  mechanisms  are  in  place 
to  oreate  a  concurrent  engmeerii^aivircmmait,  then  indivxluals  can  perfiorm  their  activities  in  their 
own  way.  Imtead  of  being  ccmstramed  by  having  to  interact  and  cooperate  with  others,  people  can, 
if  they  choose,  be  independent  and  work  akme.  Their  data  will  be  integrated.  In  this  way,  the  full 
auUmiation  of  the  industrial  environment  will  provide  the  needed  teamworic.  The  entrepreneurial 
^kit  does  not  have  to  be  stifled  by  buuness-imposed  interactions.  Independent  inoovators  can 
ctmtinue  to  be  indepmutent-at  least  in  the  way  they  operate  personally. 

Consequmitly,  concurrent  engineering  and  all  it  represents  a  not  necessarily  antagonistic  to  our 
culture.  In  fact,  the  creation  of  a  cormurrent  engineering  environment  through  information 
technokjgy  can  free  people  aixl  businesses  to  do  what  they  do  best  In  tire  U.S.,  concurrent 
enginemng  can  provide  the  cooperation  that  allows  us  to  continue  to  be  independent  entrepreneurs. 
Qmcurratt  engineering  can  meld  a  large  number  of  small,  hi^ily  specialized,  vibrant  and  dynamic 
technology  ccrntpanies  into  a  position  of  global  competitiveness.  It  can  provkle  tire  benefits  to 
industry  vertiod  and  Iwrizontal  integration  without  undesirable  restrktions.  It  may  provide  a 
uniquely  U.S.-st^  cooperative  business  struamc. 
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V.  PRODUCT  DATA  STANDARDS  ARE  THE  KEY  TO  CONCURRENT 
ENGINEERING 

The  critical  ingredient  for  the  use  of  concurrent  engineering  in  manufacturing  is  the  integration  of 
prodimt  and  process  data.  This  integration  gives  the  desigoer,  along  with  everyone  else  in  the 
commercialization  chain,  information  about  the  entire  life  cycle  of  a  product,  as  weU  as  information 
about  how  their  decisions  affect  all  other  aspects  of  the  product  In  addition,  the  integration  and 
automation  of  product  and  process  data  proves  for  meeting  the  needs  of  the  specialists  involved 
with  a  product’s  commercialization  by  aUowing  each  of  them  to  obtain  a  particular  "view”  of  the 
product  that  is  suitable  for  their  specialty  and  fiinctioiL 

Within  a  single  enterpr^  the  ^ue  may  be  more  one  of  technology  than  standards.  Sometimes  a 
company  can  choose  to  use  systems  from  one  vendor  for  all  applications,  or  it  can  develop  the 
interfaces,  translators  and  other  software  needed  to  integrate  its  systems.  But  whenever  more  than 
one  company  cooperates  or  shares  information,  interoperability  of  systems  becomes  the  uppermost 
issue,  and  that  means  starulards.  (Standards  do  not  guarantee  interoperability,  but  th^  bring  it 
closer  to  reality.) 

The  integration  of  product  and  process  data  is  not  possible  unless  there  is  a  mechanism  that  allows 
the  sharing  of  information  among  different  manufacturing  systems.  The  mechanism  must  be  a 
standard  digital  representatkm  for  product  and  process  data.  That  is  why  product  data  standards 
are  the  key  to  multi-enterprise  concurrent  engineering  and  why,  in  today’s  business  environment, 
concurrent  enfftteermg  is  impossUrle  without  standards. 


A.  The  Path  Frma  Aatoouthm  to  Concaireat  EagfaMcriBg 

Automation  in  manufacturing  has  led  to  impressive  economic  benefits  from  improvements  in 
capacity,  productivity  and  product  quality.  Yet,  the  benefits  that  remain  unrealized  are  even  greater. 
Th^  are  the  benefits  that  will  accrue  from  the  integration  of  information  among  automated  systems. 
The  benefits  include: 

Reduced  time  from  amc^  to  commerdaiization.  The  efficient  sharing  of  product  data  among 
automated  systems  will  eliminate  the  need  to  produce  hard  copy  drawings  and  models. 
Design  details  can  be  tested  electronically  against  physical  and  engineering  constraints  using 
analysis  systems  and  against  economic  constraints  using  cost  prediction  and  manufacturing 
process  simulation  ^tems.  Design  changes  can  be  made  rapidly  even  after  initial  production 
has  begun. 

Reduced  costs.  Increased  productivity  will  be  obtained  by  the  increased  efficiency  of  the 
design  process  (discussed  in  Section  m)  and  by  reduced  "time  to  maritet"  Studies  have 
diown  that  concurrent  engineering  results  in  a  reduction  in  the  number  of  design  changes 
and  in  the  amount  of  material  wasted  due  to  defects  and  rework  [1]. 

Iru:reased  resptmsiveness  to  customerneeds.  By  improving  the  fletibility  of  the  bond  between 
design  and  production,  manufacturers  can  more  quickly  introduce  new  products  or  change 
exBting  products.  This  capability  is  essential  in  today’s  global  markets.  The  demands  by 
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customers  for  both  prodm:ts  and  services  that  are  characterized  by  differeotiation, 
oastomizatk}!!,  and  localization,  result  in  a  competitive  enwonment  where  the  rewards  go 
to  the  speedkst  and  qukkest  to  adapt 

Increased  axjperatkm  among suf^diers  and  vendors.  The  abOity  to  communicate  and  exchange 
in£mmatk}n  among  suppliers  automatical^  spreads  tim  bermfits  of  integration  from  within 
a  sir^  enterprise  to  a  network  of  enterprises.  For  example,  a  single  design  change  in  oik 
component  can  cause  an  unpredictable  delay  as  its  effects  cascade  through  all  enterprises 
whose  components  and  processes  are  required  by  the  product  Today,  even  tlm  oe^  to 
evaluate  the  impact  of  a  design  change  on  the  product  causes  delays  as  different  enterprises 
communicate  and  respond.  However,  integration  would  not  onfy  allow  manufactmers  to 
coordinate  activities  a^  product  changes  among  all  their  suppliers  to  avo^  delays,  but  even 
more  importantly,  it  also  would  allow  manufacturers  aiul  suppliers  to  take  any  required 
actkins  automatically  and  sinudtaneousfy. 

The  integration  of  information  meara  the  merging  of  machines  and  information  into  a  system  that 

is  responsive  and  efiBcient~a  system  that  can  support  concurrent  engineering. 


1.  A  Higher  Level  of  Automation 

Typically,  many  different  computer-aided  tools  require  access  to  computerized  product  data.  The 
pr^uct  data  represents  ail  the  information  about  the  product,  includhig  the  product’s  function,  its 
design,  the  reasons  for  its  design  features,  and  the  manufacturing  processes  that  are  used  to  make 
it  Ideally,  the  data  also  desoibes  how  the  product  is  to  be  us^  or  operated,  how  it  is  to  be 
maintained  and  repaired,  and  how  it  is  to  be  property  deactivated  or  disposed  ot 

The  computer-aided  tools  and  computerized  information  systems  that  use  product  data  are 
essentially  very  large  computer  programs.  They  were  develop^  over  many  years  by  many  people. 
Because  th^  were  developed  independently,  they  tend  to  use  unique  representations  for  storing 
data.  Unfortunately,  each  system  is  only  able  to  use  data  that  Iul.  been  stored  in  the  particular 
representation  that  it  accepts. 

The  probtem  of  integrating  these  systems  is  the  same  problem  of  communicating  among  people  who 
speak  different  languages.  Eadi  time  product  information  is  transferred  from  one  system  to  tfae  next 
it  must  be  translated  or  reformatt^  Obviously,  having  to  perform  this  extra  step  to  share 
information  inefficient  aikl  oostty.  The  costs  muidpty  when  many  systems  are  involved.  The 
number  of  different  translaUns  required  for  a  number  of  different  systems  to  communicate  is  the 
sc  rare  of  the  number  of  systems. 

Tte  primary  reason  usually  cited  for  using  information  systems  technology  is  to  reduce  costs. 
Ironkalty,  the  iiKX>mpatibility  among  existing  information  systems  has  the  opposite  effect:  it 
inoeases  costs.  A  solution  must  be  found  that  enabl'^  the  sharing  of  product  data  among  different 
manufacturing  information  ^tems.  The  key  to  the  solution  is  a  standard  for  product  data 
represmitation  and  exchange. 

Achieving  the  goal  of  concurrent  engiimermg  and  the  economic  benefits  it  represents,  is  hindered 
not  only  by  exktiag  iocempatibiUtia  but  also  by  the  complex  nature  of  the  data  that  must  be  shared 
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among  systetos.  Hm  manufacturing  data  that  must  be  shared  is  more  than  just  an  accumulation  of 
unrelated  bits  of  numerical  information.  Design  data  provides  a  good  example;  it  contains  physical 
ami  ftumtional  information  as  well  as  informatkin  about  the  significance  of  the  design  decisions  that 
led  to  the  final  design.  Product  data  includes  not  only  the  design  data  itself,  but  also  data  about  its 
supporting  infrasmicture  and  its  interfaces  with  other  equipment. 

Therefore,  the  staitdardization  of  product  data  implies  more  than  merely  the  standardization  of 
product  data  file  formats.  For  concurrent  engmeering.  information  models  for  product  data  are 
needed.  The  path  fiom  automation  to  concurrent  enpzwering  is  through  standardized  product  data 
models. 

to  the  goal  of  conciurrent  engineering  is  the  ability  of  manufacturing  information  systems  to 
capture  automatically  the  knowledge  that  is  generated  during  the  product  life  (^cie.  The  knowledge 
can  then  be  used  by  the  designer  and  others  involved  in  managing  the  product  For  example, 
knowtedge  about  hew  a  product  would  be  processml  or  what  new  materials  wouki  be  required  to 
meet  the  functional  specifications  is  made  available  to  the  designer  as  the  design  is  being  developed 
to  emure  the  best  quality  product  reaches  the  downstream  life  cycte  managers.  In  this  way  the  most 
appropriate  and  cost-effective  materials  arxl  processes  can  be  used. 

In  a  sense,  two  attributes  of  integration  can  elevate  automation  to  a  higher  tew:l: 

1.  The  abiliQr  to  capture  automatically  Urn  knowledge  gained  during  designing, 
producing,  commercializing,  and  managing  a  product  throughout  its  lifetime,  and 

2.  The  ability  to  exchange  automatically  that  product  knowledge  among  different 
computer  systems. 

An  integrated  level  of  automation  can  be  thought  of  as  a  facilitating  or  an  enabling  technology  for 
concurrent  engineering. 


2.  Technical  Issues  in  Shared  Databases 

Automated  systems  store  product  information  digitally  in  a  database.  The  mechanism  for  sharing 
dm  information  is  a  multi-user  or  "shared”  database.  In  a  shared  database  environment,  the  product 
information  can  be  accessed  by  one  or  mote  applications,  even  at  the  same  time. 

Of  course,  there  are  many  technical  issues  that  must  be  resolved  for  such  a  shared  database 
environment  to  be  implemented.  As  was  already  described  in  Section  m,  an  interface  is  needed 
between  present  computer-aided  design  representations  of  a  product  and  other  computer-aided 
systems,  such  as  computer-aided  engineering  analysis  and  process  planning  systems.  Production  costs 
and  capabilitws  must  be  integrated  into  the  database  for  effective  design  decisions. 

Intelligent  processes  must  have  acce»  to  geometry  data  in  much  the  same  matmer  that  users  query 
bitfiness  systems.  In  addition,  it  is  critical  to  have  a  mechanism  that  allows  new  Imowledge  to  be 
added  to  the  database  as  the  intelligent  processing  operattons  are  being  performed. 
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Tlie  tccluilail  chaUeoge  k  ihe  dcveiqpaieat  of  the  infomatiaQ  i«£iij»^cfy  tod  the  aatodated 
standanli  that  anU  ticsfine  the  eovwxBBCot  for  the  reprcKotaiioe  of  product  Icocwlodie.  This  nvili 
attow  the  tmpkmeiitatioQ  ^  a  shared-databaae  eoviromaoit  for  ocMucurreat  et^^ioeeniig. 


B.  tlw  Pl^S/SnVP  EM 

POES,  which  stands  fo»r  Troduct  Data  Eachaofe  using  STEP,*  refots  to  the  U  J.  activities  m  supptm 
of  the  da«lcpcii«tt  at  an  tiu«iiatkwaJ  standard  for  product  dau  tharnog  informally  called  STEP, 
the  "Standard  for  the  Eschange  of  Product  Model  Data."  POES  wOl  ht^  estidtlish  a  nandaid  digital 
repi^enutkm  for  product  data.  The  qrcciBcttioaa  already  developed  by  the  POES  t^fort  have  been 
submitted  to  the  foteraatiooal  Organiation  for  Standaidiatioa  (ISO)  ai  a  baas  for  the  evoMiig 
intenuttioiial  standard  STEP.  As  the  POES  and  STEP  efforts  sham  comracm  goah,  they  are 
scmietmies  rt^esred  to  joittti^  m  "POES/STEP."  or  simply  just  as  "STEP." 

It  is  important  to  reoogniae  that  STEl  is  more  than  ^  ‘sodard  for  the  repmeatation  of  product 
data.  The  development  of  STEP  k  a  pioneering  tiuii  indudes  the  mearch  and  development  cf 
the  infomutdon  tecfmology  necessary  for  Jut  envisioned  thered-databau  envimvnenL  Once  this 
standard  and  its  enviroament  are  in  place,  all  types  of  eaterptite  information  can  be  more  easily 
shared. 


1.  A  New  Approach  To  ^andards 

To  achieve  the  goab  of  the  POES/STEP  effort,  a  new  approach  m  the  sundards-maJdng  process  is 
requited.  This  approach  fkiditatea  cooperative  dcvelopmem  df  the  requirement,  the  iaformatkx} 
tedinoiogy,  and  the  spec^kmtioat  sanuhaneoualy-before  the  cxisteace  ot  commercial  ^sterns  that 
can  use  the  capabihtks  of  the  standard. 

The  techndogy  does  not  yet  exist  to  define  a  product  and  its  associated  pre^Hutaes  and  characteristics 
compkti^.  Even  if  thh  could  be  done  now,  the  tedinoiogy  does  not  exist  to  cmnmunicate  Urn 
infcxrmatkm  eketronkafly  and  to  interpret  it  directly  by  the  wide  wiety  dl  automated  systons 
associated  with  the  product’s  life  cyde.  Ihmefore,  cmfy  a  process  for  creati^  standards  at  the  same 
time  the  technok^  is  being  created  will  succeed  for  STEP. 

The  creatkm  of  ^aedficatkms  for  the  standard  represeotatioQ  of  product  data  invt^ves  many  osmpfoc 
tiiues.  It  requires  a  number  of  dififorent  infomatioa  and  manufiseturing  system  technok^ks  and  the 
expemnre  ol  mmy  difforent  kinds  of  technical  experts.  Institutional  support  fo^  voluntary  natfonai 
and  itttematfooal  standards  organizations  is  provided  by  businesaes  and  industria!  comortia  and 
government  a^ncks. 

There  is  a  great  need  for  omsensus.  Industry  users  and  software  vendors  mist  cooperate  closely 
throughout  the  preccxnpetitive  redinoiogy  development  and  the  standardization  processes. 

In  addition,  it  is  enential  that  the  standardization  process  includes  i%}rous  testing  to  determine  that 
the  standarck  meet  the  needh  of  the  user  ocmimunities.  Testing  is  discimed  in  Section  C  The 
Techiucai  ChaUenge  of  STEP. 
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Z  Govenuaaat  Needs  and  PDES/STEP 

Ta  1968,  an  ad  hoc  US.  govenunent  mterageocy  task  group  was  framed  to  foaa  on  information 
diaring  amcmg  intocested  federal  agenciea.  The  objectivei  the  group  wope  to:  'prepare  and 
omsc^idate  govenuiuent  requirements  uq>ut  inU)  PDES  development  activitks,  and  provide 
rectnnmendatkMis  as  to  technical  and  other  actkms  such  as  needed  polk^  chaiiges,  regulatory  chai^ 
(X  ctmtrwtual  vehkfes/took  (e.g.  data  ittmt  descriptions,  contraa  dauses,  etc.)  which  the  government 
shcnild  put  in  place  to  foster  the  development  of  the  PDES  spedficatkni*  [16].  Smne  of  the  coikx^ 
about  the  current  product  data  envircHunent  eipiesaed  in  the  task  grmtp  report  are: 

•  It  is  hard-copy  oriented. 

•  It  is  massively  heterogeneous  in  terms  of  vendors  and  system  age. 

•  Product  knowledge  is  not  weQ  captured. 

•  Product  cycles  (fit^  RdbD  to  pn^uction)  are  very  long  and  the  handoff  &om  one  phase 

to  the  next  phase  often  loses  informatxHi. 

•  Tetdinical  data  packages  ate  often  in  error  and  incomplete. 

•  Incorporation  of  changes  and  technok^  upgrades  is  slow. 

•  New  efforts  often  just  autcnnate  methcxls. 

•  Transfer  informatkm  to  and  from  contn^tors  is  slow. 

•  Funding  for  'non-product”  developmaait  such  as  PDES  is  limited  and  sometimes  non¬ 

existent 

•  Acquisition  of  improved  tecdmology  (e.g,  new  computers  and  CAD/CAM/CAE)  is  difficult, 

time  consuming  (average  3  to  5  years),  and  deme  in  the  face  of  ever-shortening 
technology  half  li^ 

•  Industry  concern  with  proprietary  data  rights  is  at  odds  with  government  desires. 

•  There  is  a  reluctance  for  legal  reasons  to  provkfe  CAD/C^  data  rather  than  part 

drawings 

•  Data  is  reputed  many  places  for  diffment  purposes  (e.g.,  non-common/non-integrated 

databases). 

PDES  is  a  major  crmipoikent  of  the  U.S.  Department  of  Defense  (DOD)  Computer-aided  Acquisition 
and  Logistic  Siqrport  (CALS)  program  [17].  CALS  is  tackling  a  related,  but  larger  scale  set  of  issues: 

•  Developing  and  testing  standards  for  digital  tedinical  information; 

•  %>oiisoring  the  development  and  demonstration  of  new  teduwlogy  for  tlm  integration  of 

technical  data  and  processes; 

•  Impimnenting  CALS  standards  in  weapon  system  contracts  and  encouraging  industry 

modernization  and  integration; 

•  Implmnenting  CALS  in  Department  of  Defense  information  system  modernization 

programs. 

The  emphasK  of  CALS  is  the  sharing  of  informatioo  by  industry  and  government  The  phifosophy 
» that  this  can  rmfy  be  accomplished  through  integrated  databases  that  can  be  accessed  by  a  varksty 
of  hetert^feneous  cemputer  systems,  as  illustrated  in  Hgure  6.  According  to  CALS,  STEP  represents 
the  methodology  to  help  acemnplish  the  goal 

Late  in  1990,  the  Department  of  Commerce  arrd  dm  Department  of  Defense  si^ed  a  Memorarrdum 
of  Understanding  (MOU)  to  "accelerate  the  development  and  deployment  of  technology  that  will 
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6.  The  CALS  program  ii  the  autoraatioii  of  data  proceuea  to  transition  bom  paper  transfer  to  digiul-information 
transfer  to  sha^  digital  information. 


result  in  higher  quality,  shorter  time  to  productioa.  aiKi  lower  costs  for  both  weapons  systons  and 
omimeidal  products."  Qted  as  esscmtial  to  this  goal  are  the  devclopmoit  of  new  tecfanok^  and 
standards  swh  as  STEP.  The  MOU  outlines  a  partnership  program  of  development,  testing,  and 
implmnentation  of  stamlards  for  product  data  easchange.  The  Department  of  Energy  and  NASA  are 
eipected  to  enter  into  similar  MOUs  with  the  Department  of  Commerce  in  this  arena. 


3.  Institutional  Aspects  of  STEP  Devek^meot 

There  are  a  number  of  orpnizations  waking  at  both  the  natkmal  and  international  leveb  to  devetop 
an  exchange  iqaedficatkan  for  product  data.  They  include  the  following  organizations: 

•  IGES/PDES  Organization 

•  ISO  TC184/SC4 

•  ANSI  US  Technical  Advisory  Group 

•  PDES,  Inc. 

•  NIST  National  PDES  Testbed 

(The  role  of  the  National  Institute  of  Standards  and  Teclmology  [NIST]  and  the  NIST  National 
PDES  Testbed  are  discussed  in  the  foUowu^  sections;  the  other  organizations  are  discussed  below.) 

KiESlPDES  OrgaUzpftiom.  The  concept  of  PDES  grew  out  of  the  Initial  Graphics  Exchange 
Specification  (IGES)  effort  At  the  tune,  the  aoonym  PDES  was  Product  Data  Exchange 
Spedficadon. 

IGES  was  first  published  in  1900  and  was  tqidated  in  1963, 1966, 1968,  and  1990  {18].  lu  goal  is  to 
allow  CAD  data  to  be  exchanged  between  systems  built  by  different  manufocturers.  When  IGES 
data  is  passed  between  dedgn  systems,  ccmskhvable  human  interpretation  aiHl  manipulation  of  data 
may  be  required.  Since  IGES  was  designed  primarify  as  a  mechanism  for  file  exchanges  between 
CAD  systems,  it  a  not  able  to  support  shared  databases  between  dissimilar  product  life  cycle 
applicatkms. 

IGES  (kvelq)ets  recognized. that  a  more  sophisticated  standard  would  be  required  to  support  the 
integration  of  different  types  of  product  life  cycle  applications.  Therefore,  the  PDES/ST^  effort 
focused  on  developing  a  complete  model  of  product  information  that  is  sufficiently  rich  to  support 
advanced  applications,  and  to  support  concurrent  engineering. 

The  U.S.  voluntary  organization  that  is  conducting  technical  activities  in  support  of  the  development 
of  PDES/STEP  h  the  IGES/PDES  Organization  (IPO)  [19].  The  IPO  is  chaired  by  the  National 
Institute  of  Standards  and  Tecimology  (NIST)  and  administered  by  the  Natioiud  Computer  Graphics 
AssodatiotL  In  196S  a  formal  study,  called  the  "PDES  Initiation  Effort,"  was  coiaiucted.  It 
established  a  framework  and  the  methodologies  for  subsequent  PDES^TEP  activitks. 
^proximatefy  200  technical  representetives  from  the  United  States  aial  other  countries  meet  four 
times  e«;h  year  to  address  PDES/STEP-related  technical  issues. 

ISO  TC194ISC4.  In  1963  a  unanimoui  agreement  was  reached  within  the  International  Organization 
for  Standardizatfon  (ISO)  on  die  need  to  create  a  single  international  standard  whkh  enables  the 
capture  of  information  to  represent  a  computerized  product  model  in  a  neuhal  form  without  loss 
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of  oompletoiess  aod  intc^ty,  thiou^boitt  the  UCe  qvle  of  «  ptodiK^  [20].  In  December  of  the  same 
year,  BO  initiated  Techna^  Cmnmittee  184  (TC184)  cm  Industrial  Automation  Systems. 
SidKxnninittee  4  (SC4)  was  fcrnned  at  that  time  to  work  m  the  area  of  representatkm  and  cndtange 
digttal  product  data. 

Cuntmtly,  twen^-five  countries  are  involved  in  the  woric  of  3C4.  Sixteen  (rf  these  countries  are 
participating  monbcmi  and  nine  are  recognized  as  observRs.  The  U.S.  is  a  partkqmting  member. 
The  SC4  Qutir  and  the  Secretariat  are  curroitly  hehl  by  NIST. 

Technical  support  for  SC4ccMnespiedcMninantly  from  its  working  groups  (WGs).  Aluamate  quarterly 
meetinfB  of  TC184/SC4/WG  level  ate  held  ooncunently  with  the  ICES/PDES  Organizatkm  quartoly 
meetinga.  Many  ai  the  same  particq>ants  fic^  the  U.S.  and  enher  countries  are  active  m 

both  orpnizations. 

In  Decembo:  1988,  the  draft  PDES  Specification,  developed  through  the  voluntary  activities  cd  the 
IG]^/PDES  Orga^^tion,  was  std>mitted  to  SC4  as  a  dr^  prc^xisal  fiar  the  international  standard 
STEP. 

ANSI  VS  Ttekmied  Adrinry  Gnmp.  The  Amczican  National  Standards  Institute  (ANSI)  is  the 
recognized  U3.  representative  to  ISO  and  provides  the  basis  fix  U.S.  participation  in  the 
intematkmal  standakb  activities  relating  to  PDES  [21].  To  ensure  that  the  positions  on  standards 
that  are  presmted  to  ISO  are  rqiresentative  U.S.  interests,  a  mechanism  has  been  estabtMied  for 
the  devek^immit  and  coordiiution  of  such  positions.  ANSI  depends  cm  the  bexfy  which  devdkaps 
national  standards  in  a  particular  tedinok^  area  to  determine  the  U.S.  position  in  relat^ 
intematioiial  standardizatkm  activities.  Sudi  bexlies  are  designated  by  ANSI  as  *US  Technical 
Advisoty  Groups”  for  specific  ISO  activities. 


As  a  participating  memba  in  ISO  TC184/SC4,  the  ANSI  US  Technical  Advisory  Group  (US  TAG) 
selects  the  U.S.  delegates  to  SC4  and  advises  the  delates  cm  how  th^  should  vote  on  issues 
presented  to  SC4.  Tte  US  TAG  usualfy  meets  at  each  IPO  quarter^  meeting. 

The  current  US  TAG  to  TC184/SC4  was  fexmed  in  1964.  Its  membership  is  ocmiprised  primarify  of 
tarhmtail  oqierts  from  the  IGES/PDES  Organizatkm.  This  type  of  representatioo  emsures  that  the 
changes  that  UiL  enginems  and  computer  scientists  believe  are  necessary  are  reported  to 
ISO  for  cemsideration.  ANSI  has  selected  NICT  to  be  the  secretariat 

PIXS,  Jhc  In  April  1968,  several  majex  U.S.  technology  companies  incorpexated  as  PDES,  Inc.  with 
the  specific  goal  of  accelerating  the  development  aod  implementation  of  PDES.  The  South  Carolina 
Reseuch  Authexity  (SCRA)  was  awarded  the  host  contract  to  provkle  management  suppext  Hm 
technical  partidpants  provi^  by  the  PDES,  Inc.  member  companies  and  SCRA’s  sul^ntractors 
ate  uiKh»r  the  direction  of  the  PDE$,  Inc.  General  Manager  from  SCRA.  At  present,  there  are 
twenqr-four  ccxnpanies  that  are  members,  including  two  foreign  companies.  Member  company’s 
canMimd  annual  sales  total  over  $400  billkm;  they  employ  over  three  mdlion  people. 

PDES,  Inc.  has  emb^  Iced  on  a  multi-phased  plan  for  the  accekxatkm  of  STEP  devdopment 
Initial^  the  canpharis  was  cm  testing  and  evaluating  a  data  exchange  implementation  of  mechanical 
parts  and  ri^  assmnblies.  Current  efforts  focus  on  the  ktontificatkm  of  sc^tware  implementation 
requimnoits,  constructkxi  of  prototypes,  and  devetopment  of  "context-driven  integrated  models"  for 
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small  mechanical  pans.  Recent^,  PDES,  Inc.  restmctured  and  broadened  the  prog^  scope  to 
indttde  such  areas  as  electnmks,  sheet  metal  and  structures.  PDES,  Inc.  a  providing  increased 
tMiA»nthip  in  the  effort  to  accelmte  the  implementation  STEP  [22].  NIST  a  a  government 
assodate  and  provides  a  testbed  faciUty  and  technical  team  members  to  support  the  PDES,  Inc. 
effort 


4.  Nature  of  STEP 

The  mat^r  different  organizatiom  and  individuals  that  are  involved  in  the  development  of  STEP  share 
a  common  interest: 

The  esteMshmentc^  a  compUu,unambiffious,  compute  defb^^ 
functional  charactaistics  c/  a  product  througfujut  it‘s  Ufe  cycle. 

As  a  standard  method  for  digital  product  definition,  STEP  will  support  communications  among 
heteiogeneoiK  computer  environments.  STEP  will  make  it  easier  n?  integrate  systems  that  perform 
various  product  life  cycle  fiinctioos,  such  as  design,  manufacturing  and  logistics  support  Automatic 
paperiess  updates  of  product  documentatkm  wiU  also  be  possible.  The  principal  technique  for 
integrating  these  ^tems  and  eachanging  data  wfll  be  the  shared  database. 

In  the  context  of  STEP,  a  product  may  range  from  a  simple  mechanical  part,  such  as  a  bolt  or  a 
screw,  to  a  complex  set  of  systems,  such  as  an  aircraft,  a  ship,  or  an  automobile.  Ultimate^,  STEP 
should  be  able  to  represent  the  informaticm  whidi  is  nee^  to  describe  all  types  of  products, 
inclialmg  mechanical,  electrical,  structural,  etc. 

STEP  addresses  maxy  questions  about  a  product:  What  does  it  look  like?  (geometric  features);  How 
is  it  constructed?  (materials  and  assembly);  For  what  function  ii  it  intended?  (structural  and 
functional  properties);  How  can  we  teU  a  g^  product  from  a  bad  one?  (tolerances  and  quality 
coitttraints^  What  are  its  components?  (biU  of  materials). 

The  STEP  specification  is  being  produced  as  a  series  of  documents  called  *parts”  [20].  Currently 
identified  parts  of  the  specification*  are: 

•  Introductory: 

Part  1.  Overview 

•  Desaipdon  Methods: 

Part  11.  The  EXPRESS  Language 

•  Implementatim  Forms: 

Part  21.*  Gear  Text  Encoding  of  the  Exchange  Structure 

•  Conformance  Teeing  Methodology  and  Framework: 

Part  31.  General  Concepts 


*This  list  of  STEP  part  titles  is  current  as  February  1991. 
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Part  32.  Requirements  cm  the  Testing  Laboratory 

•  Imegnaed  Resources: 

Part  41.  Fundamentab  of  Product  Description  and  Support 

Part  4X  Geometric  and  Tc^iogical  Representatkm 

Part  43.  Representatimi  Spedalizatkm 

Part  44.  Product  Structure  Configuration 

Part  45.  Materiab 

Part  46.  PreKntatkm 

Part  47.  ^pe  Toieranoes 

Part  48.  Form  Features 

Part  49.  Product  lifie  C^cle  Support 

•  AppScation  Resources: 

Part  101.  Draughting 
Part  102.  Ship  Structures 
Part  104.  Finite  Elmnent  Analysb 
Part  105.  Kinematia 

•  Apfdkation  Protocols: 

Part  201.  Explicit  Drau^ting 

Part  202.  Assodatrve  Drau^ting 

Part  203.  Comfiguration  QmtroUed  Design 

Part  204.  Medianical  Design  Using  Boundary  Representation 

Part  205.  Mechanical  Design  Usmg  Surface  Repr^ntatkm 

The  number  and  titles  of  the  parts  are  likely  to  change  often  as  new  needs  are  identified;  exbting 
parts  may  be  revised  or  additional  parts  may  be  added  to  the  standard. 

There  are  likely  to  be  many  additional  applkatkm  protooc^  Thb  b  because  applkatkm  protocob 
are  coitral  both  to  progress  in  improving  and  completing  STEP  and  in  commercializing  it 
^jpUcation  protoads  are  discussed  in  the  next  section. 

STEP  b  defined  and  represented  officially  in  the  EXPRESS  programming  language  [23].  EXPRESS 
was  designed  to  represent  infmmatkm  modeb  in  a  form  proces^le  by  computers.  The  STEP 
EXPRESS  model,  called  a  "conceptual  schana,"  ctefines  and  identifies  the  "olqects,”  or  "entities,”  that 
can  be  used  by  STEP  applications.  In  the  first  implementatkm  form,  STEP  product  modeb  will  be 
cichanged  uung  a  STEP  "plqisical  file"  [24].  EXPRESS  b  still  being  modified  and  improved  to  meet 
the  ne^  STEP.  It  wfll  ultimately  become  an  ISO  standard  (Part  11  of  STEP). 

IDEFIX  b  a  modeling  language  that  has  bemi  used  to  represent  STEP  graphically  [25].  EXPRESS- 
Gb  a  newer  modeling  language  extension  to  EXPRESS.  Examples  of  EXPRESS-G  and  EXPRESS 
rqireseatatkHis  of  two  «mple  STEP  entities  are  shown  in  Figure  7.  Thme  are  a  variety  of  software 
available  fm  procesMiig  EXPRESS  [26]. 
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Fig.  7.  STEP  entities  in  the  graphica!  modeling  Ungui^  EXPRESS’D  cube  mapped  directly  to  the  EXPRESS  kuigiuige 
format  that  ia  used  for  the  standard. 


5.  C(Hom«:cializati(»  STEP 

Represeautives  from  induttiy  have  key  rok$  in  each  of  the  orfutizatkHH  workiiig  to  develop  STEP. 
Industiy  mutt  deSue  the  requironentt  for  STEP  and  mutt  amume  the  mott  critical  rok  of 
impfen^ting  commc^daily  viabk  STEP-bated  tyatemt.  Aftm*  thete  syttemt  are  impkmented. 
induttiy  and  government  wQl  have  to  coordinate  their  ^hmt  to  trantirion  jc^tly  fokn  odtting 
infimnatioa  tyatemt  to  thote  baaed  up<»  STEP. 

The  ultimate  obiective  PDES/STEP  acdvitiet  it  the  commercial  availability  of  STEP-baied 
tyitemt.  Cniimeicial  ^stem  developen  need: 

•  Technical  apedficationt  that  are  aound  and  eaay  to  implement, 

•  CommeidaJfy  fair  ttandaidt  that  do  not  £iw  omnpetitcus,  and 

•  A  large  pc^ential  market  for  thdr  produt^ 

To  entuie  that  STEP  it  a  tucoett,  it  it  neoeaaaiy  that  the  foundatkm  be  built  while  the  tpedfkatfont 
are  atiU  under  development  The  problemt  and  itiuet  that  will  eventually  be  faced  by  lystem 
developen  and  uten  mutt  be  kknti^  and  addietted  before  the  apedficatioot  become  ttandardi. 

Vemkns  of  qatema  that  win  uae  STEP  need  to  foel  confident  that  the  atandard  it  complete, 
omaiatent  and  atable  beficue  th^  win  invest  in  devek^mmit  efiortt.  Vendcns  mutt  have  easy  accesa 
fo  the  mott  current  veiskmt  of  STEP.  Hdp  ahcwkl  be  fieefy  availabk  to  attiat  their  undentanding 
of  the  standard  and  how  to  implemmit  h.  Finally,  ventkin  need  to  know  that  there  it  a  cleaiiy 
defined  market  fin  lystemt  that  employ  STEP. 

Vemkns  wffl  use  application  protocoit  to  build  their  products.  For  this  leasmi,  the  strategy  is  to 
implement  STEP  thiou^  aiqilicatkm  protocoit,  and  to  extend  STEP  through  the  development  of 
new  appycatkm  protooA  t^t  bring  new  entitiet  into  the  standard  as  thdr  need  it  identified. 

Apphcatkm  protocols  wfll  be  standards  that  define  the  ocmtext,  the  uae,  and  the  kind  product  data 
that  must  be  in  STEP  fin  a  ^lecific  manufacturing  purpose  in  a  product’s  life  tycle,  sudi  as  design, 
I»ocett  planning,  and  NC  programming  [27].  Applintkm  protocoit  standardize  the  use  of  STEP  to 
support  a  particular  mamdacturing  function  teiiabiy  and  consistently. 

An  application  protocd  ccmsistt  of  [28]: 

1.  An  application  refetenoe  model  that  specifies  the  kind  of  data  required  to  perform 
a  parlicular  purpose,  in  terms  that  are  appropriate  and  familiar  to  experts  in  the 
aj^licatkm  area, 

2.  An  application  intmpreted  model  that  defines  how  the  STEP  data  is  to  be  used  to 
present  the  information  specified  in  the  application  reference  model, 

3.  Dooimentatkm  that  describes  bow  the  information  is  used  and  exchanged,  and 

4.  A  set  t^confixmance  requirements  and  test  purposes.  A  corresponding  abstract  test 
suite  win  be  developed  for  each  applicatfon  protocoL 
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The  ccmimerdalizatx>o  STEP  is  intimatefy  tied  into  the  devebpment  and  a»if(c»mance  testing  of 
application  protocol. 


6.  Haimonizatkm  Among  Different  Types  of  Product  Stamlanb 

Hanncmization,  involves  the  integration,  or  consolidation,  of  standard  that  may  be  overlapping  or 
fiTwiflictifiginto  an  unttobiguous  setof  standards  that  are  ccmsistent,  ct»npatS>le,  and  complemcntaiy. 
Hannonizatkm  rqnesmits  a  browl  and  compkx  challenge;  it  must  deal  with  different  of  both 
emting  and  anwging  standards  in  a  vari^  o[  industries.  Because  PDES/STEP  d^lopment 
ac^ties  ate  addiesung  the  undofying  enabling  tedinologies,  PDES/STEP  can  contribute  to 
harmonization  all  pr^uct  standards. 

However,  even  if  there  were  no  ovmlap  or  otmflict  amoi^  product  data  standards,  harmonization 
would  st31  be  necessary  because  oranplex  products  indude  a  varied  types  of  ocanponents,  and 
ther^ore  thdr  manufacture  requires  medianical,  electrical,  and  other  typa  of  data. 

Unttar  the  auspices  of  the  industrial  Automatkm  banning  Panel  of  ANSI,  an  (»ganization  called  the 
Dighal  Representation  of  Product  Data  Standards  Harmonization  Organization  was  formed  to 
lacOitate  the  efficacious  use  of  digital  representatkm  standards  providing  a  forum  Rx  ooordinatfon, 
planning,  and  guidance  to  standards  developets  and  approvers”  Tbeharmrmizationorganizatfon 
has  as  a  long-term  objective  an  integrated  set  of  stamlards  ttot  can  support,  in  digital  form,  the 
definition  of  products  for  aU  aspects  of  tbdr  life  cycles. 

The  C^ganizaticxi  mtends  initially  to  support  dBEcnts  to  intqrate  four  standards  sanctioned  by  ANSI 
that  address  the  representation  and  czriiange  of  product  d^nition  for  ela:tronic  products,  and  to 
help  harmonize  them  with  STEP.  These  standards,  used  in  electrical,  electronic,  and 
electromechanical  design  and  manufscturing,  have  coiniderabie  overlap  and  conflict  arxi  ate  not 
ccmriMait  with  STEP.  Thqr  indude: 

•  VHDL,  *Vety  High  ^)eed  Integrated  Qrcuit  (VHSIC)  Hardware  Description  Language,” 

an  algebra-like  description  that  a  used  to  doign  oomplez  logic  for  chips  and 
computers, 

•  EDIF,  "Electronic  Design  Interchange  Format,”  a  file  format  for  communicating  two- 

dimensional  graph^  and  intenxmnectkm  information  that  is  often  used  to  desoibe 
the  pattons  that  ate  used  to  fabricate  semiccmductor  chips, 

•  Institute  Cm  Intercormecting  and  Padcaging  Electronic  Circuits  (EPC)  Series  350,  used  to 

describe  the  patterns  and  median^  process  to  manufacture  printed  circuit  boards, 
and 

•  IGES,  "Initial  Graphics  Exchange  %)ecification,”  toed  to  represent  the  three-dimensional 

geometry  of  objects. 

Companies  that  produce  electronic  products  often  must  use  all  four  of  tlmse  starulards. 
Unfimtunately,  since  the  standards  do  not  went  well  together,  the  prexluct  information  often  must 
be  remitered  into  differemt  onnputets  as  the  product  progresses  through  its  life  cycle  stages. 

The  Organizatkm  must  first  defiim  the  means  for  an  integrated  network  of  digital  prodwrt  data 
standards  and  the  tkffinitkm  of  a  common  modeling  methodology  for  all  product  data  standards.  (In 
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STEP,  EXPRE^  it  the  specification  language  and  IDEFIX  »  oiw  of  several  modeling  tools.)  Once 
a  methodology  it  accept^  all  product  data  standards  models  could  be  inte^ted  into  one  model 
There  would  alto  be  a  cmnmon  gioasaty  o(  terms  and  a  dictkmaiy  of  data  entity 

Another  aspect  may  be  a  structure  or  'taxoncmiy*  that  defines  the  interrelationships  among  all 
product  techncdog^  Such  a  taxfmomy  could  bectmie  a  "romlmap*  for  future  standards  activitks 
and  extensaoDs  to  ending  staitdards. 


C  The  Technical  danwgr  of  STEP 

There  are  four  ms^  technical  challenges  fadng  the  developot  STEP: 

•  The  exchange  o(  data  is  dififerent  Cnmi  the  exchange  of  infimmation.  I^ta  must  be 

transmitted  accurately  and  without  arqr  changes.  In  omtrast,  information,  although  composed 
of  data,  must  be  uraderstood  and  interpreted  by  the  receiver.  Furthermore,  the  receiver  must 
be  aUe  to  appfy  the  ’ifrnmatkm  cmiectly  in  new  situations.  The  first  challenge  is  that  STEP 
is  a  standard  Ui  iurmadon,  not  just  dam. 

•  The  need  for  STEP  to  be  extendable  to  new  products,  processes,  and  techixilogies,  requites 
a  more  abstract  representation  oi  die  information  than  in  previous  standards.  Regardless 
of  their  eququnent  os  {»ooess,  a  user  must  be  able  to  obtain  the  information  necessary  to  do 
somethii^  fimn  the  STEP  rqiresmitatkm  (rf  a  product  Thmefoie,  the  second  chaltenge  is 
thatthedevelapmaitafSTEPrmtstmctudeAedevdopmentafan''arduucture’'oraJmneivork 
far  the  esduuigs  of  irrformatioH,  rtot  ptst  a  rneans  or  fonnat  for  raorir^  iirfoimatkm. 

•  The  wide  range  of  industries  and  the  drvenity  of  product  information  coveted  in  STEP  is 
beyond  that  of  any  previous  digital  standard.  The  varieqrctf  attributes  and  parameters,  such 
as  gemnetric  sfaa^  mediankal  fimctkm,  materials,  assembly  information,  and  date  of 
manufacture,  is  immense.  Ain,  the  industrial  base,  the  num^  of  industry  involved,  is 
enormous  even  greater  is  the  number  of  technical  disdpiines  that  ate  involved.  Moreover, 
STEP  must  be  flexSde  and  extensfole  n  that  new  infiemation  and  additional  application 
prmocols  can  be  mlded  and  can  be  upwardly  compatible.  Therefore,  the  thud  cludlenge  is 
that  die  xope  and  armplesity  cf  STEP  is  far  beyond  any  previous  standards  effort. 

•  Traditkmally,  standardizatxm  is  a  process  that  devises  an  approadh  encompassing  a  variety 
Of  existing  vaid<»s*  options,  builds  on  the  best  sedution  available,  and  avoids  penalizing  some 
vendors  more  than  othos.  In  the  case  of  STEP,  there  is  no  existing  implementatioa.  Thus 
the  fourth  chaUenge:  the  technology  to  mpport  STEP  must  be  devdoped  as  the  sanu!  time  dte 
standard  is  evoMrtg. 

The  oonsensiK  approach  to  meeting  the  above  challenges  is  to  start  with  conceptual  information 
models  [30].  STEP  wOl  cemskt  of  a  set  of  clearly  and  formally  defirmd  conceptual  models  ami  a 
physical  eschar^  protocol  based  <ni  these  modek  The  conceptual  models  will  be  combined  into 
a  modd  with  a  standard  interface  to  a  shared  database  [31]. 

The  fcdlowtng  sectkms  describe  the  approaches  laed  by  the  community  that  is  woildng  to  develop 
and  imphm^t  STEP  succe^iilly. 
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1.  Data  Sharing 


Cteariy,  it  is  not  the  pti^skal  hardware  connectioDS  between  computers  that  is  ti^  major  issue  in  data 
riiaring;  it  is  inoompatibie  software.  The  root  of  the  problem  is  proprietary  data  representations, 
that  is,  veiitkv-sped£k;  data  formats,  hfote  often  than  not,  the  vendors  of  computer  applicatioin 
sUxe  tite  data  which  is  required  and  produced  by  their  systems  in  their  own  proprkstary  format 

For  example,  once  the  design  of  the  product  has  been  completed  on  a  CAD  ^tem,  it  is  stored  in 
a  data  file.  Scnne  of  the  information  in  that  data  file  represents  the  shape  and  size  of  the  product 
In  an  integrated  informatiini  systems  envinmment  the  d^gner  should  be  able  to  send  that  data  fife 
ovm  to  tlm  manufacturing  planning  system.  Ihe  same  data  would  then  be  used  by  the  planning 
^tem  to  determine  manufocturing  processes  for  the  product  based  in  part  on  its  specified  shape 
size. 

If  the  planning  system  can  read  the  omtents  of  the  design  data  file,  it  can  obtain  the  shape  and  size 
information  it  needs.  It  might  be  said  that  these  two  applications  ate  integrated.  But  it  is  a  fact 
today  that  if  two  commercial  products  are  integrated,  it  is  likefy  that  they  were  developed  by  and 
purchased  finxn  the  same  vendor.  Furthermore,  it  is  also  likely  t^t  they  were  intentiona%  designed 
to  work  together  from  their  inception.  Oftmi,  it  is  the  case  todi^  that  applicatioix  offered  by  the 
same  oMnpai^  are  not  integrated 

STEP  is  intended  to  address  the  issue  of  produm  data  sharing  between  different  computer 
applications  running  on  differcmt  computer  i^tems  within  the  same  or  different  organization.  STEP 
will  provide  a  standard,  neutral  fixmat  fix  product  data  created  and  shared  by  different  applications. 
Neutral  means  that  the  STEP  data  format  will  not  favor  one  particular  vendor. 

IGES  is  an  example  of  a  neutral  data  exchange  format  [18].  IGES  was  originally  intended  to  provide 
a  means  fix  exi^anpng  engineering  drawing  data  tetween  CAD  systems.  One  problem  that 
occurred  with  IGES  is  an  ou^rowth  of  the  way  vendors  implement  the  software  that  is  required  to 
translate  their  data  to  and  from  the  neutral  IGES  data  file.  Currently,  a  vendor’s  translator  can 
oeate  IGES  data  files  wfaidi  omtain  data  that  makes  sense  in  the  context  of  their  system.  When 
that  same  IGES  data  file  is  foaded  into  another  vendor’s  ^tem,  an  incomplete  data  translation  can 
occur  became  the  second  vendor’s  translator  has  made  a  different  set  of  assumptions  about  the  data 
it  is  receiving. 

STEP  goes  beyowl  IGES  both  in  the  breadth  of  its  information  content  and  in  the  sophistication  of 
its  inf(xmatk>n  ^tem  methodologies.  In  addition,  STEP  development  is  including  the  definition  of 
subsets  of  product  data  that  are  specifically  required  for  particular  usage  contexts.  These  subsets 
are  called  application  protocols. 


2.  App^tkm  Protocob 

STEP  applkatkm  protocob  address  the  bsues  of  completeness  and  unambiguity  of  data  transfer  by 
iqiedfyifiq;  in  advai^  what  data  slrould  be  transferred  in  a  particular  context-thereby  alleviating  the 
need  fix  ven^rs  to  make  problematic  assumptions.  Application  protocob  are  those  parts  of  STEP 
that  are  relevant  to  a  particular  data>sharing  scenario  [27]. 
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As  expiained  in  the  previous  section  under  "Commercialization  of  STEP,”  the  development  of 
applintion  protocols  permits  the  incremental  impkmaentatmn  of  STEP.  There  will  be  many  STEP 
application  protocols. 

Tk  conospt  an  applmatwn  protocol  allows  veixlon  to  build  an  applicatk>n  system  that  can 
interface  with  STEP  data  in  a  standard  manner.  In  a  sense,  an  application  protocol  is  a  starKlardized 
way  of  implementing  a  portkrn  of  STEP  for  a  specific  application.  It  is  almost  like  a  recipe  for 
budding  an  application  [32].  The  functional  ccunponents  are  illustrated  in  Eguxe  8  and  a  flow 
diagram  of  st^  in  tlm  development  of  an  application  protocol  are  shown  in  Hgute  9. 

Hie  development  of  an  application  protocol  involves  incorporating  speci&  application  requirements 
into  STEP,  then  testing  tte  application  protocol  for  compteteness,  correctness,  compliance,  and  self- 
omsistency.  It  is  an  iterative  process  [32]. 

Among  the  technical  issues  being  resolved  are: 

•  How  application  protocols  will  communicate  with  each  other  and  share  product  data, 

•  Whether  application  protocols  will  be  independent  of  the  way  in  which  the  product  data 

is  used  (for  example,  vdiether  the  data  is  shared  or  exchanged^ 

•  Whether  a  commerdal  application  must  impietaent  an  entire  application  protocol  or  if  it 

can  utilize  a  subset  of  the  application  protocol,  and 

•  How,  and  whether,  information  not  already  contained  in  STEP  but  needed  by  a  new 

application  protocol  will  be  added  to  STEP. 

Hie  technical  challen^  involved  in  the  development  of  application  protocols  are  central  to  the  use 
of  STEP.  Their  development  and  implementation  wiU  ^termine  whether  STEP  "can  actually 
support  crmiplete,  unambiguous  exchimge  of  product  data  aooss  several  applkatkm  system 
boundaries”  [32].  Application  protocol  development  wUl  force  solutions  to  many  of  the  remaining 
issues  i«lated  to  the  usefulness  and  practicality  of  STEP  itselL 


3.  Data  Representations 

At  the  core  of  the  data  sharing  problem  is  data  representation.  STEP  defines  the  information  that 
describes  products  within  different  computer  applicatkms  and  across  difEerent  enterprises.  Hm  use 
of  ccnnputer  software  requires  that  the  shared-data  representations  be  specified.  Data 
representatkm  schemes  must  identify  the  data  elements  involved,  their  format,  tlmir  meaning,  and 
th^  relation  to  each  other.  Data  representatkms  are  formally  defined  within  STEP  sped&ations. 

For  example,  in  the  geometry  portion  of  the  STEP  specification,  a  simple  data  element  may  be 
called  "point"  The  data  representation  for  "point”  might  consist  of  thnx  aspects:  the  point’s  X 
coordinate,  its  Y  coordinate,  and  its  Z  coordinate.  To  complete  the  data  representation,  the  type 
of  numbers  allowed  for  the  point’s  X,  Y,  and  Z  coordinates  must  be  oq)licitly  stated.  In  this  case 
they  would  be  "real"  numbms,  not  integers  or  xriK>le  numbms.  Having  defined  the  data 
rqjresmitation  for  "point,"  other  more  complex  data  elements  can  also  be  defined  that  make  use  of 
the  "point"  data  elraent 
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The  five  components  of  an  application  protocol  are  the  scope,  the  ARM,  the  AIM, 
the  conformance  requirements,  and  the  usage  guide. 


Ing.  9.  The  steps  in  the  devck^ment  of  an  applicatioa  protocol  involve  continual  feecRjadc  to  MHUie  that  the  apphcaikm 
protocol  meets  the  ncc^ 


Representatkxit  &Hr  data  ekmeott  can  beocnne  quite  complex,  making  them  difiBcult  to  define  and 
undeistand.  The  moat  impcxtant  oiterion  fior  the  data  representatkHtt  uied  in  STEP  is  that  they 
mint  be  unamb^uous.  This  prevents  then  being  misinterpreted  by  applkations.  or  being  interpreted 
diSerentl^  by  different  applkatk  us.  Ambiguous  data  repreaentaUtms  lead  to  problems  like  wires 
bemg  rnktal^  6nr  ccmduits,  or  bolts  bemg  mistaken  for  machine  screws. 

The  devekspers  STEP  empk^  infc»mation-modeling  techniqiics  to  ensure  that  S'lEP  will  be 
unambiguous.  An  iiffcmaation  modeliog  language  is  actually  us^  to  defiix  p(»tions  of  the  STEP 
spedficaticHi.  Impiemmitaticms  of  STEP  ate  written  in  EXPRESS  [23].  EXPRESS  has  many 
featioes  of  a  ccaaputtt  programming  language.  Writing  STEP  in  EGRESS  allows  information 
modeling  expert  to  use  iqmdaiized  computer  sttftware  to  chedt  the  integrity,  validity,  and  effanency 
of  STEP.  Besides  facilitating  the  <fa:vdopment  o(  the  standard  itself,  these  infimnation  modeling 
techniques  will  abo  help  to  ^Msed  the  (tevdq)fflent  of  future  st^twaie  appUcatkms  based  upon  STEP. 

STEP  is  organiaed  into  a  framewmk  oompoted  of  application  information  models,  resource  data 
models,  and  generic  data  models  p3].  The  generic  data  models,  which  int^rate  the  resource  data 
models,  are  the  Generic  Product  Data  Model  and  the  Genak  Entorprise  Data  Model  [34].  Tim 
Generic  ^oduct  Data  Model  (GPDM)  contains  information  ccnnmon  !o  all  products  and  meets  tim 
needs  applicatkm  protocds  by  providing  for  the  intmpretation  of  generic  facts  in  contemj 

[27].  The  GPDM  consists  the  schemas:  omtext,  product  definition,  property  definition,  and  shape 
representatioo.  Currentty,  the  definitkms  of  the  schemas,  in  EXPRESS,  ate: 

flximjxmtextjKfaema 

applicatkmjmmxxil 

pr^uctjcontcxt 

product jdefittition^context 

gpdm_productjdefinitionjKdmma 

product 

product_categoiy 

product_veiskm 

productjdefinitioo 

productjdefinition^equivalence 

productjdefinitk>n_relatiooship 

QKlmj)roperty_definitkHi_schema 

product^material 

product^shape 

shape^aspect 

surfoce_fiiiish 

gpdm_shape_represeniiatk)njKhema 

shape_model 

shape_model_oompositkm 

shape_model_representatioo 

The  STEP  data->sbaring  architecture  must  be  able  to  access  the  data  wherever  and  however  it  b 
stmed.  The  data  will  be  in  a  fcHrm  dktat^  by  the  STEP  Generic  Product  Data  Modd.  A  STEP 
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data  access  inter&ce  may  be  tbe  method  used  to  provkle  application  systems  with  the  STEP  data 
imeded  to  peifoim  an  application  [22]. 


4.  Tedmkal  Ewjlution  of  STEP 

A  sound  technical  sped&atkm  for  STEP  must  address  many  issues  pertaining  to  the  ardiitectures 
of  infmmation  systems  and  the  management  of  product  life  ^cle  data.  Many  different  technolqjlies 
have  been  brou^t  tt^ether  to  establish  a  technical  foundation  for  STEP.  Computor-aided  design 
and  solid  modeling  ^tmns  provided  the  initial  framework  fim  describing  product  data.  The  Gelds 
of  informatkm  modeling,  relational  and  object-oriented  database  management  systems  have  provkled 
software  tools  that  have  contributed  to  the  development  effort.  Technical  experts  who  are  familiar 
with  the  data  requirements  of  design,  process  enguaeering,  machine  programming,  and  produa 
support  systems  have  helped  deGne  the  types  of  data  that  must  be  supported  in  a  product  data 
exchange  spedGcation. 

Because  of  the  broad  range  of  product  ^pes  and  application  technolo|^  which  must  be  owered, 
the  transformation  of  Sl^  an  abstract  ccmcept  to  a  commordal  reality  is  an  evolutionary 
process.  STEP  application  areas  range  from  simple  mechanical  parts  to  complex  electronics  systems 
to  buildings  and  sUps.  STEP  is  undergc^  four  stages  of  evtdutkm: 

Stage  1:  Establishment  of  the  foundation  for  STEP.  The  oreation  of  a  spedGcation  for  the 
standard  representation  of  product  data  involves  many  complex  issues.  It  is  virtually 
impossible  for  one  individual  or  even  a  smaU  group  oi  individuals  to  write  this  kind  of 
SpedGcation.  Tbe  devek^mmit  ctf  this  spedGcation  requires  both  a  strong  technical  and 
insGtutkmal  foundatkm.  The  technical  foundation  for  STEP  is  baaed  upon  a  number  of 
diffemit  information  and  manufacturing  ^sterns  technologies  ami  the  experience  of  many 
technical  oqierts.  The  institutional  foundation  is  provided  by  vduntary  r«yhnir.iti  activities, 
national  and  international  standards  o^anizations,  businesses  and  industrial  consortia,  ami 
government  agencies.  Because  df  the  great  need  for  consensus,  all  of  these  institutions  must 
be  in  general  apeement  about  the  content  of  STEP,  if  it  is  going  to  be  an  effective  standard. 

Stage  2:  Validation  and  standardization  of  technical  specifications.  Once  an  initial 
spwif^tion  has  been  created,  it  must  be  validated,  that  is,  test^  to  determiim  that  it  meets 
the  needs  of  the  user  community.  Validatfon  testing  takes  into  account  how  the  spedGcation 
will  be  loed.  Technical  experts  deGne  the  requirements  for  the  different  Idmls  of  software 
applkatfons  that  wfll  use  STEP  and  buOd  information  models  based  on  the  proposed  STEP 
standards.  These  information  models  are  then  tested  to  determim;  whether  will  meet 
tlw  neecte  of  state-of-the-art  software  applications.  Test  criteria,  test  procedures,  and  test 
data  are  also  developed  as  part  of  the  v^ation  process.  Only  after  satisfactoiy  test  results 
are  achieved  can  the  spedGcation  be  considered  workable  and  comptete.  The  results  and 
reccmimendations  generated  by  validation  testing  flow  badt  to  tbe  standards  organizations 
for  review  and  action. 

Stage  3:  Developmoa  tools  and  prou^ipe  apidications.  The  development  of  commerdal 
STEP-based  software  products  can  be  acceterated  by  prototyping.  The  developers  of  these 
ptotoqrpe  ^tems  will  team  a  lot  about  using  STEP  technology  that  will  help  to  accelerate 
the  (tewlopmmit  of  comment  products.  software  tools  that  are  developed  may  also 
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be  und  in  future  products.  If  this  wnrk  it  done  in  the  public  domain,  many  companies  can 
benefit  from  the  results  of  this  effort  Furthermore,  earfy  prototype  appUcatfons  can  be  lated 
to  validate  the  suitability  of  proposed  standards.  Th^  can  aiuj  be  used  for  integratkm 
testing,  that  is,  testing  to  (tetermine  vdiether  or  not  different  types  of  applkatfons  can  work 
togetimr.  Prototype  systems  also  may  be  extended  to  exerene  conformance  testing  tystems. 
In  the  absence  of  these  prototype  implementatkms,  vendors  and  custtnnerB  may  make  claims 
conformance  throu^  seif-testing. 

Stage4.  ContmercwUzatkm  of  and  transition  to  STEP-^Htsedsyitans.  Ultimatety,  STEP-based 
tystems  must  be  developed  and  marketed  oommmmally.  It  will  take  a  number  of  years  for 
industry  to  tecopize  all  of  the  different  spedalty  niches  for  these  tyttems  and  to  develop 
stable  products.  Certainly  th»  phenomenon  can  be  seen  in  the  personal  ccmiputer  maritet 
Althouj^  the  basic  interface  specifications  for  PCs  were  establisl^  in  the  early  1960’s,  new 
types  of  hardware  and  software  products  are  still  being  defined  today.  It  wQl  undoidjtedty 
take  a  number  of  years  after  products  become  availabfe  until  they  are  put  into  wide^read 
use  within  industry  aixl  govenunent  Connderable  advanced  planning  and  investment  of 
resources  will  be  required  to  transform  large  government  and  industrial  organizatiems  into 
new  STEP-based  tystems.  Traiolation  planning  is  essential  to  implementation  and 
acc^tance  of  STEP. 

The  first  stage  of  STEP  evolutkm  is  well  undmway,  but  the  second  stage  has  just  barely  started. 
Stages  2  tluough  4  win  also  have  to  be  repeated  for  the  different  product  techrolo^es  t^t  STEP 
must  cover,  such  as  medhanical  assembli^  sheet  metal  parts,  structural  systems,  and  etectronks 
components. 


5.  Verification  and  Validation 

Vmificatkm  and  validation  are  two  ways  in  vtiiich  commerdalization  of  STEP-based  products  can 
be  expedited.  Ver^icadon  is  the  review  both  the  tystem  requirements  to  ensure  that  the  right 
problm  is  being  solved  and  the  tystem  design  to  see  that  it  meets  those  requirements.  Vaiidadon 
is  the  test  and  evaluation  of  the  integrated  system  to  determine  compliance  with  the  functional, 
performance  and  interface  requirements  that  were  verified.  Validation  and  verification  are  necessary 
during  the  devek^ment  of  STEP  and  its  associated  software  tools,  as  weU  as  fim  the  development 
SlEP-frased  p^ucts,  that  is,  STEP  implementations. 

With  respect  to  the  development  of  STEP,  validation  requites  testing  to  confirm  that  the 
requiremmits  for  the  product  life  cycle  data  have  been  me  One  of  Urn  major  goals  of  the  validation 
teeing  efforts  is  to  test  the  suitability  of  the  proposed  STEP  standard  for  product  life  cycle 
infemnation  tystems  applications. 


Validation  testing  is  aimed  at  evaluating  the  completeness  and  the  integrity  of  the  STEP 
spedficatkms.  \^ttout  validation  testing,  many  dei^ndes  in  the  specificatfons  might  not  be 
diioovered  until  ccmimerciai  applications  are  constructed.  It  is  obvious  that  without  this  testing, 
devek^jers  might  have  bad  to  b<^  the  burden  of  excessive  redevelopment  costs  and  delays  while  the 
tyiedfications  are  "fixed.” 

Validation  testing  is  discussed  menu  thoroughly  in  Section  E  Tim  NIST  National  PDES  Testbed. 
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6.  /^)|dicatk»  ^tems 


Applicatioii  ^stons  axe  Ums  computer  software  qstmns  that  wOl  use  STEP.  They  are  systems  fior 
axuputer-based  manufacturing  fiunctiona  such  as  cmnputer-aided  (kssign,  analysis,  manufacturing 
{banning,  resource  allocation  and  scheduling,  manufacturing  equ^mient  programming,  and  quality 
assurance.  Matty  oi  these  tystems  have  cmnmoo  data  requiiemmits  and  th^  need  to  share  data. 
(A  rimple  example  dt  shared  data  is  the  name  df  the  product  and  the  kkmtifiai  df  its  component 
parts.)  The  ea^  development  of  prototype  STEP  applkatkm  tystems  is  the  key  way  to  accelerate 
ccxnmcatcialization  S'i'HP. 

Scxne  product  data  requirements  may  be  unique  to  a  spedUBc  type  of  application.  For  example,  the 
tolmances  on  a  product’s  dimensions  would  be  required  by  manufacturing  planning  tyStems,  but  this 
same  data  wouM  be  irrelevant  to  MhadiiKng  systems.  Yet  both  tystmns  would  n&t  to  the  same 
names  vriien  identi^mig  the  product  aixl  its  components. 

Ensuring  that  STEP  addresses  the  requirements  for  manufacturing  applications  is  a  significant 
chaUmige.  (This  was  discussed  in  the  ocmtext  applkatkm  protocols.)  Generally,  there  are  no 
formal,  publicly  available  spedficatkms  ci  the  inforoation  requirements  fix  aity  of  these  systems. 
Functional  requirements  arid  des^  spedficatkms  must  be  dcvdkjped  for  tystems  that  wOl  use  SIEP. 
These  q)ecifiadi(ms  should  be  ddlned  ooncurroitly  wfih  the  evdving  applkatkm  protocols.  Th^ 
will  hdp  to  determine  exactly  how  STEP  will  be  used  tty  fiiture  commeidal  tystems. 

Prototype  application  systems  should  be  devek^md  that  can  be  used  to  test  the  viabOity  of  the 
applkatkm  protocds.  Different  types  oi  prototype  systems  should  be  tested  with  eadi  other  to 
ensure  that  STEP  permits  intercqierabiiity  betveen  various  applkatkms.  If  the  prototypes  are 
constructed  in  the  publk  domain,  thty  can  later  be  used  as  fimndatkms  and  building  bkxda  fix 
commmcial  implmiientations. 


7.  Omfiguration  Management 

The  process  of  develqmig  an  infixmatkm  processing  standard  invcrfves  the  creation  ami  managemmit 
of  thousands  of  documents  and  computer  programs.  Knowing  which  documents  and  computer 
prc^rams  are  current  uid  vritkdi  ate  obsolete  is  critical  to  the  devdopment  process.  Configuration 
management  provides  the  fundamental  opm.  tkmal  capability  fix  tracking  and  maintaining  versiom 
ctf  documents  and  software. 

Craf^iratfon  is  the  logical  grouping  and/or  collection  of  elements  into  a  coherent  unit  Thk  unit 
tt  typkalfy  a  version  of  a  software  release  or  text  document  If  the  configuration  of  an  information 
unit  is  to  be  controlled,  access  and  changes  to  the  information  must  be  controlled.  Often  "master” 
documents  and  approval  mechanisms  are  established  to  ensure  the  quality  and  integrity  Of  the 
infixmation  that  is  bdng  managed. 

The  (xmiplexity  of  the  confignratkm  management  problem  is  governed  by  tlm  type  of  information 
mvdved  and  how  it  is  to  be  controlled.  In  the  case  of  simple  configuration  control  systems,  for 
example  those  that  cfeal  with  sctftware  source  code  control,  simple  text  files  ate  usually  just  groupoi 
togetlMBr  iitio  a  named  or  numbered  unit  and  distributed  as  a  single  item.  This  is  a  simple  process 
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and  many  sc^hvaie  prodimts  curroitfy  peifoim  just  this  function.  The  ctnnpkxity  of  the  problem 
increases  when  the  configuration  invcrives  more  than  just  simple  text  files.  Two  examples  of  more 
complicated  ooii%uratiDn  amtrcd  problems  are  the  managemmit  of  ccnnputer  programs  which  run 
<Bi  difEment  computer  systeoBS,  and  docummits  which  include  graphic  images. 

Clea^,  the  develq>m«it  of  STEP  is  a  ocmiplex  configuratioii  managmnent  probtem.  It  involves  a 
number  of  different  organizations  that  have  different  intoests  in  the  techniral  aspects  and  in  the 
sutus  of  the  proposed  standard.  Each  cnganization  must  be  able  to  retrieve  proper  verskms  of  the 
developing  stamhud.  Software  tools  ate  needed  vdiich  can  be  used  to  merge  electronic  vmions  of 
text  and  produce  a  sin^  unified  document  firom  each  organization’s  ocmtiftutioos.  This  assembly 
prooen  is  cme  the  main  fiinctkxis  a  good  configuration  management  system.  Reliabb^ 
controlled,  and  iq>-to>date  access  to  an  individual  organization’s  data  plus  the  capability  to  puU 
disparate  pieces  of  infixmation  together  is  a  mqtx  chaUei^ 

Tbe  discusuon  of  colouration  management  h  continued  in  Section  E.,  The  NIST  Natkmai  PDES 
Testbed. 


8.  Qmfotmanoe  Testing 

Be&xe  commerdaily  devek^ied  rqfmerns  are  marketed,  conformance  testing  procedures  must  be 
establistied  vdudi  act  as  quality  assurance  medianisms  to  protect  both  system  developers  and  users. 
Ccmformance  testing  is  the  evahiatkm  process  or  methodology  that  is  used  to  assess  whether 
products  adhme  to  standards  o  spedfications.  If  independoit  conformance  testing 

medtanisffls  ate  not  established,  customers  wOl  have  U>  accept  vendor  assurances  that  their  systems 
comply  with  STEP.  Unfimtunately,  many  vendon  may  be  incapable  of  determining  whether  or  not 
thw  products  faithfully  ccnnply  with  the  standard. 

The  devekqiment  of  omformanoe  testing  methods  and  the  devdc^iment  of  applkatkm  protocols  are 
intertwined.  Commercial  systems  based  upcm  one  cn  more  application  protocols  will  be  the  fost 
impicanentations  ctf  STEP.  Confimnance  testing  methods  for  STEP  will  only  be  based  cm  evaluating 
implementations  application  profoxds. 


D.  lleRoleorNlSm  An  Fnglnswlng  PasmBpi 

Researdh  and  hands-on  experience  are  essential  for  scientists  and  ei^;ineers  to  make  informed 

and  impartial  standards  recommendations.  Realizing  the  importance  of  manufacturing  interface 
standanb,  NIST  estabUsbed  the  Automated  Manufacturing  Research  Facility  (AMRF)  in  1960  to 
mvestigate  critical  issues  in  factory  automation  standards.  The  first  major  goal  of  the  AMRF 
involved  the  construction  of  a  fleadble  manufacturing  system,  a  testb^  for  the  smaU-batch 
mant^acturing  environment 

The  finality  is  used  as  a  labmatory  by  government,  industry,  and  academic  researchers  to  develop, 
test  and  equate  potential  interface  standards.  To  ervuie  that  the  interface  standards  issue  is 
addressed,  the  lesfoed  is  dengned  to  ccmtain  oomponent  modules  fiom  a  variety  of  vendors  [3S]. 
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Ibe  AMRF  repreaoits  a  &«sh  appioach  to  £M^ory  autcnnation.  The  genak  factory  archi^ure 
inoEMrporatea  elnnaita  such  as  hinaichkal  fadlity  oxittdl,  distributed  database  management, 
ocmimuiucatkmiietworic  protoo^  <»i<]ine  prooesscontrcd  (deterministic  metrok^),  data-driven  (ami 
feature-drivcm)  processes,  and  manufacture  data  prqmratkm  (such  asdes^  process  planning,  and 
ofif-Iiiie  equ^iment  {nogrammmg). 

It  is  this  eatpetkaice  in  building  a  large-scale  testbed  facility,  wmking  with  industry  and  univerrities, 
studying  stmrdards  issues,  and  implmnoitii^  testbed  solutions  that  brings  NIST  to  an  impc»tant  role 
in  the  devek^ment  luid  implemcmutkm  ai  PDES/STEP. 


1.  Components  of  the  NBrr  Engineeriiig  Paradigm 

Traditionalfy,  engineering  projects  have  been  carried  out  by  starting  with  qredfications,  devek^ing 
or  mli^ting  technology,  and  developing  the  requited  applicatkm.  Today,  the  management  of 
infic»mation-espeda]ly  infinmation  in  electronic  hmn-lm  become  a  critical  compcmmit  of  any 
engineaing  endeavOT.  This  is  especially  true  in  the  work  of  the  NIST  Factory  Automation  ^tems 
DiviskMt,  vrime  much  the  PDES/SIEP  wmk  at  NIST  is  dtme.  The  paradigm  can  be  used  as  a 
modd  fim  understanding  and  plamung  engineering  projects. 

The  paradigm  consists  of  four  omiponents: 

•  System  ^redficatkm, 

•  Information  Managmnent  Technology, 

•  Engineering  Techndogy,  and 

•  Engineering  Apphcatkm, 

The  paradigm  is  drown  diagrammatically  in  Figure  lOi  The  qntem  qiedfication  compcment  takes 
an  hidustriai  need  such  as  'manufacturing  worid-dass  products”  and  develops  the  infiormation  and 
fiinctioaalmodds  that  address  the  needs.  The  informatkmmaiuigcDimBttechiiology  component  takes 
the  dandards,  in  tins  case  product  and  manufacturing  data  standards,  and  generates  the  information 
fian»work  or  archftectedure  omoqrts  required  to  implemoit  an  engineeriiig  apphcatkm.  The 
eiq;ineaing  techncdogy  component  takes  the  functional  requirements  fim  the  applications  as 
ddermined  by  the  qntmn  specfficaticm  and  creates  the  engineeting  framework  or  architecture 
concqrts  required  to  implemmit  the  ei^ineeting  application.  Finally,  the  engineering  application 
component  is  the  int<^tk»  of  the  two  tedmology  components  into  a  prototype  application 
enwrwmMaBt  to  test  frilly  the  proposed  set  of  standards.  The  aqperienoe  gai^  in  the  application 
eaviromnoit  is  used  to  sttei^hen  the  system  spedficatkm  amponent  The  outputs  are  Indicated 
by  the  dotdrle-Iined  arrows;  a  set  ctfstandardsfii^  the  ^tmnqiecificationoompcMiait  and  products 
from  die  migineering  application  componmiL 

The  comlnnatkm  a£  the  need  fr>r  advances  in  ccmcurrent  engineering  technok^ies  and  the  need  to 
rquescmt  o^ineeriim  data  in  a  riandard  fixmat-STEP-is  a  pofiect  industrial  prc^lem  to  be 
implmmnted  using  the  oigineerii^  parad^.  This  is  illustrated  in  Hgure  11  and  the  following 
discuision. 
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Product 

The  relatiomhipi  among  the  four  otnnpoiienU  ci  the  engineerinf  paradigm  involve  models  and  omoepts  that  cany 
out  the  transfer  of  information  among  the  components.  The  double-lined  arrows  represent  inputs  to  and  outputs 
from  the  intern  (for  example,  needs,  standards  and  products). 


2.  %stem  Specification 


The  functicm  ctf  the  first  parad^  componoit,  system  spedficatioa,  is  to  take  industrial  needs  and 
devdc^  the  infiannatkHi  and  functional  specifications  required  to  solve  them.  These  specifications 
beccnne  the  basis  for  the  devek^moit  the  informatkm  and  engineering  technologies  required  to 
implCTent  a  solution  to  the  industrial  needs.  Mott  of  the  activities  performed  in  this  component  are 
involved  with  the  vohintary  national  and  inimnational  standards  programs. 

Ther^re,  in  the  paradigm  as  applied  to  |»oduct  data-driven  engineering,  system  spedficatkm  is  tlm 
development  of  tte  STEP  standard  as  an  ISO  data  exchange  standard  and  the  implementation  of 
applkatkm  protocols  that  specify  the  engineerit^  ravmmmoit  in  a^h  STEP  is  to  be  used.  NIST 
participates  in  both  the  formal  standards  organization  and  in  the  research  and  development  of  testing 
procedures  for  STEP.  A  staff  member  serves  as  diair  of  the  volunteer  IGES/PD!^  Organization. 
Staff  also  activefy  participate  in  the  tedmkai  committees  within  the  IGES/PDES  Organization  where 
robust  infomatkm  mot^  that  define  the  scc^  and  application  of  STEP  are  dev^ped. 

NIST  scientists  are  invcdved  in  appfying  to  STEP  the  Information  Resource  Dictkmary  System 
(IRDS)  standard  bdng  devetoped  by  ANSI  p6].  There  is  a  project  that  addresses  the  applicatioo 
of  IRDS  to  STEP,  including  using  an  IRDS  extendibOify  feature  to  stqjport  the  storage  and 
management  of  the  diverse  ccmoq}^  and  data  mo&b  of  STEP.  In  addition,  work  is  going  on  to 
ezteiKl  the  STEPinfomatkm  resource  dictkmary  sdiema  to  support  a  full  three-schema  architecture, 
tt>  interface  STEP  IRDS  to  software  sudi  as  ccmceptual  modeling  tods  and  database  management 
systems,  and  to  develop  relationships  to  physical  design  fo  STEP. 

NIST  staff  are  involved  also  in  identifying  the  applkatkm  of  gefmietrk  modeling  to  the  definition 
STEP  and  its  applkatkm  implemmitatkms.  Thoe  ate  many  technfcal  issues,  such  as: 

•  IntmKiionbetw^d^mMmodeUng  geometry  syaenu.  As  an  example,  for  NURBS 
(Non  Unifotm  Rational  B-Spline)  sutfeces,  what  is  the  best  transformation  fiom  a 
5th-ofder  curve  to  a  series  of  3td-order  curves.  In  general,  how  is  getmietrk 
information  exchanged  betwmen  constructive  solid  geometry,  boundary,  and  wireframe 
models. 

•  Topology  and  its  reU^onMps  to  gMmetry. 

•  Geometry  and  topohgy  and  duir  rdadonship  to  a/ydication  areas  such  as  numerical 
cotmd  (NIC)  coding  gyu^hks  t&play,  coUidon  detection,  etc. 

An  overriding  issue  a  the  problem  of  deckUng  what  type  of  geometrk  modeler  is  appropriate  for 
a  ^ven  application.  Research  into  how  to  categorize  modeler  parameters  and  measure  expected 
paformance  fo  applications  sudi  as  inspectkm  and  N/C  coding  is  also  important. 

NIST  staff  participate  in  the  development  of  testing  procedures  for  STEP  as  well  as  STEP-based 
indu^rial  products.  They  have  devsdoped  test  plan  that  kfoitify  the  approaches,  methodology, 
testmtces,  and  tadcs  required  to  test  and  validate  STEP.  There  are  many  common  testing  methods 
diat  wfil  be  oqplored  indudiiig,  test  data  file,  syntax  analysis,  smnantk  anafysis,  instaime  tables,  and 
ad  hoc  database  queries. 
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Testing  ctf  the  specificatton  and  implementations  axe  pcnft^med  at  the  National  PDES  Testbed, 
descri^  in  the  next  sectkm.  The  testbed  will  become  a  model  for  a  network  of  future  testbeds  that 
wSl  be  established  throughout  the  workL  The  Testbed  will  also  serve  as  a  model  for  the  type  of 
software  and  hardware  configurations  and  personnel  resources  needed  to  test  aiui  implement  STEP. 


3.  Infimnatxm  Management  Tedinology 

The  functwn  of  the  infcmnation  managonent  techndk^  component  is  to  devek^  the  proper 
tedmdc^  to  process  the  information  idmitified  in  the  systmn  spedfication.  The  important  point  to 
be  stressed  is  that  the  tedinology  (file  ^tem  or  relational  database,  for  example)  must  be 
appropriate  to  meet  the  needs  of  the  engineerii^  techndogy.  The  folhswing  are  typi^  tasks  to  be 
perfmmed: 

•  Detenttine  front  the  mfonnahon  model  ^pec^icatum  the  types  of  data  r^resetuations 
required.  Areas  of  concern  include  the  impl^entatkm  of  a  data  dictionary,  the  types 
of  schemas  for  representing  the  informational  relatbnsh4)S,  and  the  extent  to  whkh 
knowledge  (rathN  than  just  infixmation)  needs  to  be  represented. 

•  Bat^  on  the  erqpteering  emvanmerO,  mck  as  fkdlde  rnamfacturu^  sysum  or  robot 
control,  detmrune  the  important  characteristics  of  the  informadon  management 
technology  needed.  The  issues  may  indude,  for  example,  distributed  vs.  central 
storage,  homogeneous  vs.  heterogeneous  computing,  version  control  (or  configuration 
management),  time  constraints,  database  size,  and  security. 

•  Des^  and  implement  an  irtformadon  management  system  capable  of  handling  the 
required  charactaisdcs. 

In  dxxt,  this  component  of  the  engineeting  paradigm  is  concerned  with  the  conversion  of  STEP  into 
an  information  management  ^tem  that  can  support  the  engineering  requirements. 


4.  Engineering  Tedinology 

The  ftinctkm  o[  the  engineering  techndogy  component  of  the  paradigm  is  to  convert  the  fimctional 
qiedfimtions  into  a  collection  of  engineeriiig  concepts  ami  a  ^tems  architecture  that  can  address 
the  industrial  probtem.  The  followiiq^  are  typical  tasks  to  be  poformed: 

•  Define  a  plan  for  developing  the  technology.  This  includes  decomposing  the  overall 
pr^lem  into  a  series  of  tasks  and  specifications. 

« 

•  Ident^  the  product  data  requirements  and  measuremertt  systems  needed.  Define  the 
control  ardutecture  and  process  interfaces.  Develop  new  engineering  concepts  to 
addscu  the  problem. 

•  Des^  the  o%wttUtysterrt,iricludiiqi  the  information  arid  fimctumalritodels.  Definethe 
data  requirements  and  the  means  by  which  data  is  to  be  collected  and  analyzed. 
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•  Determine  which  processes  are  ne&ied  for  the  given  appScahon,  for  exampie,  process 
plamung  or  robot  handBr^ 


5.  Engmeeriog  ^plication 

The  fourth  a>mpoiient,  engineering  appIicatkKi,  is  prototyping  of  the  concepts  and  architecture 
ddSned  in  the  two  components,  infonnatkm  managemmxt  tec^ology  and  enpneering  technok)]^. 
The  mi^uts  oi  the  en^neering  application  component  are  feasibility  demonstrations  oi  how  the 
engineming  and  information  management  concepts  result  in  a  credible  solutfoiL  The  following  are 
typical  tasks  that  are  performed: 

•  Based  on  the  systems  specification  and  the  technology  to  be  deveU^red,  spedfy  the 
product  mix  to  be  used  in  the  laboratory. 

•  DeveU^  the  intafaces  between  die  informadai  management  systems  and  the  engmeering 
protxsses.  Devdop  the  interfaces  between  the  various  processes  that  compose  the 
mgineering  applicatioiL 

•  BuM  a  laboratory  based  on  the  ardtitecture  and  concepts  darned  for  the  informaticm 
andenffneerir^techrudogies.  Design  and  perform  e3q)eriments  that  provide  the  proof- 
of-concept  for  the  technologies. 

The  engineering  application  paradigm  component  is  realized  as  a  laboratory  in  which  the 
ardritecture  and  concepts  <kvek>ped  in  the  information  management  and  engineering  technologies 
amponents  are  implemmited.  Facilities  that  represent  processes  that  ate  part  of  the  product  life 
cycle  ate  built  and  esperiments  are  omducted  to  test  the  technology  concepts. 

At  present,  the  AMRF  can  be  viewed  as  the  en^neming  application  for  the  subset  of  the  product 
life  qide  that  addresses  the  design,  manufaauring  and  inspection  processes.  The  work  in 
manufacturing  data  preparation,  process  control,  and  factory  control  addresses  the  engineering 
tedincdr^ies  for  flexible  manufacturing.  There  are  also  efforts  in  data  management  and  network 
communications  that  address  the  information  management  technology  hsues. 

The  factory  control  tystem  for  the  manufacturing  and  inspection  of  parts  uses  a  STEP-like  format 
The  tystmns  are  all  data  driven.  In  fact,  the  vertkal  woristation  is  driven  from  an  off-line 
programming  environment  that  starts  from  a  set  df  machinable  features  for  a  part  [37].  Tim 
inspection  workstation  is  driven  from  an  off-line  programming  environment  that  generates  a  CAD 
dambase  of  the  part  with  respect  to  the  necessary  tolerance  information  [38].  The  fi^m-level  control 
ardiitecture  developed  wit^  the  AMRF  iua  become  a  model  for  the  implementation  of 
manufacturing  systems. 

A  common  thread  throughout  the  AMRF  is  the  standardized  method  of  handling  data.  This  is 
particttlarty  true  in  the  manufacturing  data  preparation  research  which  is  aimed  at  a  seamless 
architecture  based  uprm  phig-ccmipatfole  modules  that  streamline  the  preparation  of  data  for 
automated  manufacturing  systmns. 
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In  the  AMRF,  incoming  part  descriptions  are  converted  to  AMRF  Part  Model  Files  using 
commercial  CAD  ^tems  and  software  developed  for  the  AMRF  [39].  The  AMRF  Part  Model  File 
includes  3-D  geometric  and  topolo^cal  information,  tolerances,  ai^  other  data  on  the  part  in  a 
uniform  format  that  can  be  used  by  otlmr  AMRF  systems.  Translators  have  been  written  to  convert 
this  tbrmat  to  STEP. 

Working  ftom  the  STEP  files,  and  other  information  in  the  database  system,  operators  then  prepare 
"process  plans"  for  the  part  In  the  AMRF,  these  computerized  plans  include  the  cell’s  "routing  slip," 
which  is  used  to  schedute  the  movement  of  materials  and  tte  assignment  of  workstations;  the 
workstation  "operation  sheets,”  which  detail  the  necessary  tools,  materials,  fixtures,  and  sequences 
of  events;  and  the  machine  tool’s  "instruction  set,"  which  guides  tlm  tool  through  the  motions 
required  to  shape  the  part  Research  is  being  condimted  into  the  development  aiul  testing  of  a  single 
set  of  standard  data  formats  for  process  plaiming  at  every  level  of  the  factory  control  hierarchy,  and 
an  editing  system  to  generate,  archive  and  update  these  plans.  In  effect  the  AMRF  provkies  a 
laboratory  for  a  STEP  implementation.  The  AMRF  approach  to  handling  data  is  to  allow  the  users 
fteedom  to  select  computers  and  database  software,  yet  still  be  able  to  build  an  "integrated"  system. 

Idealfy,  a  factory  control  or  platming  system  should  be  able  to  request  the  information  it  needs 
without  knowing  which  of  several  databases  holds  the  information,  or  what  format  is  used  to  store 
the  data.  A  distributed  database  management  system  called  the  Integrated  Manufacturing  Data 
Administration  System  (IMDAS)  is  used  in  tlm  AMRF  to  meet  this  need  [40]. 

The  AMRF  data  communkations  system  allows  computer  processes  such  as  control  programs  to  run 
on  mat^  different  computers  and  to  be  developed  using  different  languages  and  operating  systems. 
This  system  uses  a  method  of  transferring  information  through  the  use  of  computer  "Mailboxes," 
which  are  areas  of  shared  memory  on  various  computen  to  which  aU  machines  have  access  throu^ 
the  network  communications  system  [41]. 

The  Manufacturing  Systems  Integration  Program  uses  the  AMRF  as  a  testbed  to  stiuly  data  and 
interface  requirements  for  commercial  manufacturing  engineering  software  systems.  The 
concentration  is  on  functions  performed  during  the  manufacturing  of  mechanical  parts,  such  as 
process  planning,  engineering  design,  tool  management  and  off-line  programming,  shown 
schematically  in  Figure  12.  The  goals  include  demonstrating  feasibility  and  testing  integration  and 
interface  concepts  for  information  standards  to  integrate  manufacturing  engineering  and  production 
tystems. 

In  essence,  the  AMRF  is  the  laboratory  where  control  and  metrology  concepts  and  architectures  for 
integrating  information  and  technologies  are  implemented  and  tested. 

Other  laboratories  in  the  Factory  Automation  Systems  Division  fulfill  the  paradigm  expectations  and 
perform  a  function  similar  to  the  AMRF  for  q}e^c  application  areas.  They  include  the  Engineeriog 
Design  Laboratory  [42],  which  is  med  to  evaluate  software  tools  for  integrating  design  and  analysis 
ami  for  modeling  d&i^  intent  and  design  knowledge  for  access  and  use  throughout  the  life  c^e 
of  a  product  Anotimr  mcample  is  the  Apparel  Design  Research  System,  which  is  used  to  help 
devefop  mettmds  for  product  data  exchange  that  are  appropriate  to  the  apparel  industry  [43].  (The 
design  project  is  funded  in  part  by  the  Defense  Advanced  Research  Projects  Agency  and  t^  apparel 
prefect  is  funded  by  Urn  Defense  Logistics  Agency.) 
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Tbe  Manufacturing  Systems  Integration  Project  builds  upon  previous  AMRF  work  in  hierarchical  cont 
architectures,  the  representation  of  manufacturing  data,  a  language  for  process  specification,  and  the  integral 
manufacturing  data  administration  system  (IMDAS). 


C.  Hi  Natlowil  POES  TwtM 


The  NIST  NatiooBl  PDES  Testbed  is  a  focus  for  planning,  ccxmiinatiott,  and  guui<ince  of 

a  natKHial  effot  for  STEP  development  and  implementation.  The  natxmal  (^forf  ax»c»s  of  s 
growing  network  of  participating  cMrganizatioaa  varfous  types. 

Located  at  the  National  Institute  Standards  mad  Techncrfogy,  the  Testbed  is  a  public^  luxemfole 
huality  where  the  STEP  spedficaticm  and  STEP*rebted  took  can  be  modeled.  anaJyzed.  prc^jiypcd, 
impleraented,  and  tested  {44}.  Hysically.  the  facilsty  is  comprised  of  liAKxmtories,  cxmputm 
hardware  and  software  ^sterns,  and  testing  tools.  The  laboratories  indude  uiuque  laboratories  «ich 
m  the  Vahdatkm  Testing  %stem,  as  well  as  multipiopose  laboratories  such  as  the  AMRF  and  the 
Engineering  Oengn  Laboratory.  The  Testbed  is  used  and  staffed  by  leading  experts  on  PDES  issues 
ftc^  industry,  academia,  aixi  govemment  It  is  cumaotly  stafEed  with  the  fuU-time  eqtuvaJent 
approximately  20  scientists,  engineers,  arxl  support  penocmeL 

The  Natfonal  POES  TeubH  supports  the  goals  of  the  IPO  and  ISO  to  establish  an  iniematkmal 
standard  for  product  data  sharing.  The  Tesfoed  was  establisfaed  at  NIST  in  1968  under  US. 
Department  of  Deferue  C^puter-aided  Acquisitkm  arid  Logistic  Support  (CALS)  profram  ftuidiitg. 
Standards  whkh  support  product  data  sharing  are  reoogniaed  as  a  ma^  buildiim  block  in  the  CALS 
program.  Under  CALS  spoasotshin,  the  Naticxal  PDES  Testbed  is  advancing  the  development  of 
product-aharir^  technologies.  The  staff  of  the  Natfonal  PDES  Tesfoed  are  not  only  irm^ved  with 
the  ISO  atrd  IK),  but  also  actively  psrtk^wte  in  the  technical  activities  cd  PDES,  li^ 

The  Testbed  is  also  the  cornerstone  of  the  ManufKturing  Data  Interface  Standards  Program  at 
NIST.  The  goal  of  this  program  is  the  development  of  natforud  standards  for  a  *papmien* 
manufKturing  and  logistic  suppOTt  system. 

The  overall  objective  of  the  Testbed  »: 

To  provide  technical  leadership  and  a  testing-based  foundation  for  the  rapid  and 
complete  developmera  of  the  STEP  specification. 

The  majOT  functions  of  the  Testbed  include: 

Standards  validation  test  developmera  to  ensure  that  the  specificatfons  ami  underlying 
information  models  meet  the  needs  product  life  cycle  systems; 

STEP  application  prototyfring  and  inim)peral»lity  testing  to  provide  test  cases,  tools  for 
germrating  test  cases,  and  appUcatfon  experts  who  can  critkally  evaluate  tl»  draft 
spedlScatioBs;  to  ensure  that  the  spedlicatfons  are  sufl^enUy  intcfpated  to  guarantee 
interoperability  of  different  types  of  STEP  appikationt;  and  to  demonstrate  iIm  advantages 
and  suitability  of  STEP  for  use  in  industrial  environments; 

Product  data  exchange  network  mtegpation  to  provide  a  natfonal  network  at  govemment  and 
iiKiustty  manufmrturing  sites  and  laboratories  to  share  informatfon  and  test  cases;  and 
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Configuratkm  mtuumemaa  to  impieiiiait  a  anij^iiratioo  masagement  intern  and  establish 
a  amtral  repositofy  for  docunteots  and  software  generated  by  varwus  organizatkms  invoKed 
in  the  S  .  EP  devek^moat  process. 


1.  Standards  VaJidatxMa  and  Ccmformanoe  Testing 

Validatkm  testing  in  the  process  that  ensures  that  STEP  is  uubfe  and  functiiMiaL  It  confirms  that 
the  standard  is  ccMnpIete,  unambiguous,  and  ocmMStent  It  determines  that  the  uandard  meets  the 
needs  of  the  user  community.  The  results  and  recommendations  generated  by  validation  testing  must 
be  fed  back  to  the  standards  organizatkms  for  review  and  actkm.  Stauiai^  ccnnmittee  members 
may  then  amend  tlw  spedficatioiis,  affected  pmtions  may  be  re-teitted,  and  the  specifications  caa  be 
approved  as  standards. 

The  emphasis  on  valklation  at  the  Testbed  is  on  the  devek^ment  of  ctunputer-assisted  tocds  for 
testing  and  evaluating  proposed  application  protocol  specifications  [28]. 

The  validatioo  process  is  evolving  along  with  STEP  itself.  Technical  challenges  still  remain,  induding 
sudi  issues  as  the  degree  of  functkmality  that  mint  be  defined  in  an  appiicatioo  protocol  amd  that 
must  be  achieved  by  application  systems. 

To  support  validatioo  testing,  the  Testbed  provides  an  integrated  computing  envircmmeoL  In 
addhioo,  it  acts  as  a  reposiuxy  tot  proof  ai  the  qualities  that  the  STEP  qa^ification  exhibits.  This 
pToot  in  the  fcxm  of  test  results  and  real-wcvkl  test  product  data,  will  help  the  standardization 
process  to  proceed  and  wiD  encourage  implementation  informatioo  systems  udiich  use  STEP. 

The  Validation  Testing  %stem  within  the  Testbed  is  cmnprised  of  software  that  will:  1)  automate 
the  evaluation  a(  the  computable  qualities,  such  as  whether  or  not  the  qmtax  of  the  specification 
language  was  followed,  and  2)  assist  valklation  teams  with  solving  intuitive  problems  whkdi  are  not 
feasible  to  auunnate.  The  names  of  the  major  ctsnpcment  modules  rtf  the  validatioo  testing  ^tem 
are: 


•  Model  Socking  and  Gmstruction  Tool 

•  Test  Definitkm  Tool 

•  Test  Case  Data  Generation  Tool 

•  Test  Case  Execution  and  Evaluation  Tool 

Figure  13  illustrates  the  major  validation  testing  took  and  their  functions. 

Jnt  as  validatfon  testing  is  essential  to  the  development  of  STEP,  conformance  testing  a  essential 
to  its  successful  implementatiorL  Conformance  testing  is  the  testing  of  a  carkiidale  prodi»:t*s 
behavior  and  capabiUties.  The  behavior  and  capabilities  of  the  product  must  be  those  required  by 
tlm  starulard  itself^  aixl  they  must  be  exactly  what  is  claimed  by  the  manufacturer  of  the  product 

Conformance  testing  helps  to  assure  product  conformity  in  implementations,  clarifies  the  standard 
itself  for  implementation,  provides  a  f^back  loop  to  the  standards-making  bodies  for  improvements 
to  the  standard,  and  encourages  commercial  development  by  providing  a  baseline  for  commonality 
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validation  toob  used  in  the  Natkmal  PDES  Testbed  include  model  scoping  and  oonstructkm,  test  deGnitkHi, 
case  generation,  and  test  execution  and  evaluation. 


in  aU  products.  It  does  not  guarantee  that  the  prodtKt  confixms  to  the  standard,  nor  does  it  assure 
that  tte  product  is  hi|^  quality  w  reliahility. 

The  implonaitatioo  df  a  ccmformance  testing  qstem  and  an  independent  testing  program  increases 
the  probability  that  different  STEP  implemoitatkms  will  be  able  to  inteit^>aate.  Hgure  14  shows 
the  conficmnance  testing  program  mocteL 

The  National  PD^  Testbed  will  construct  a  conformance  testing  tystem  [4S].  bt  coc^Nsratkm  with 
othos,  the  Testbed  plans  to  devek^  test  procedures  and  data  that  adhme  to  STEP  applicatkm 
protocols,  specify  the  process  which  wiD  be  used  for  certifying  compliamm  with  the  standmd,  and 
dc^ne  the  procedure  whidi  will  be  used  to  approve  and  review  the  opmrations  of  testing  Idxiratemes. 
The  Testb^  intends  to  help  establkh  a  ccmfcnmance  testing  program  at  selected  sites  on  the  Product 
Data  Exchange  Networic. 

The  standardization  and  acceptance  of  a  conformance  testing  methodology,  as  well  as  appropriate 
test  metlxxb  will  allow  producers  to  test  their  own  products  throu^  a  testing  laboratory  aib  will 
tead  to  acceptance  of  test  results  fitom  different  testing  laboratories. 


2.  Application  Prenotyping  and  Intmoperability  Testing 

For  applicatkm  prototyping  and  intmr^ierability  testing,  the  Testbed  indludes  a  "STEP  PtoductioD 
CelL”  The  STEP  Produetkm  Cell  will  dmnrmstrate  small  batch  manufacturing  using  STEP  data  [46]. 
It  will  be  an  int^rated,  autcmiated  manufacturing  environmost  within  the  NICT  AMRF  whose 
product  specification  data  representation  k  baaed  upon  validated  STEP  data  models.  It  wiU  help 
verify  that  the  STEP  standard  is  workable  thrcHigh  production  level  testing.  In  cooperation  with  test 
sites  having  similar  captfoOities,  the  STEP  Production  Cell  will  test  and  demonstrate  how  STEP 
supports  production  opmtioiis  occuning  at  diffnent  sites. 

The  STEP  Production  Ceil  will  integrate  basic  STEP  software  tools,  commercial  databases,  and 
commerdal  manufacturing  applkatkms  into  a  prototype  small-scale  manufacturing  environment, 
tliqthin  this  environment,  it  ^  be  possible  to  verify  the  paformaime  STEP  under  real-world 
ccmdltkms  and  to  dmnoiBtrate  STEP-based  manufacturing  across  different  production  sites. 

The  manufacturing  data  preparation  subsystems  of  the  STEP  Production  CeU  are  design,  process 
planning,  and  equipment  programmir^  These  subsystems  are  used  to  generate  the  information  that 
is  requited  to  control  the  manufacture  and  inspection  of  a  part  STEP  data  is  the  primary 
infmmatkm  shared  by  these  subtystems. 

Within  the  cell,  the  Machining  Woricstation  is  a  3-axis  vertical  milling  machine.  This  computer-driven 
machine  tool  can  produce  simple,  prismatic  parts.  The  computer  programs  that  control  this  machiim 
tool  are  derived  from  the  ST^  data  provi^  by  the  manufacturing  data  preparation  subsystems. 

The  inspection  wOTkstatioo,  a  coordinate  measuring  madiirre,  provides  tlm  fadlity  for  determining 
whmher  madhined  parts  are  produced  as  specified.  Based  on  measurements  from  the  coordinate 
measuring  machine,  analysis  software  determines  whether  dimensions  of  the  madiined  part  fall 
within  dengned  tolerances.  As  with  the  milling  machine,  the  computer  programs  that  control  tlm 
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14.  Confotmaiice  testing  and  oertiScatiott  is  a  d^icted  in  the  confrannance 
process  mocteL 
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mettuiement  ptocess  are  derived  fitom  the  STEP  data  provided  by  the  fflanufacturtog  data 
preparatioB  sub^teou. 

Hie  data  ieporitc»y  subitem  providea  the  storage  rc'ichanitm  ior  STEP  data.  The  xepauuxy 
I»ovuks  a  geoak  ac^tware  interface  to  the  data  representations.  The  genetic  interface  aOowt  the 
application  sidnystons  to  sti»e  and  retrieve  the  desired  STEP  data  without  regard  to  the  details  of 
its  rqpresentatioiL  The  network  communications  nib^ton  ties  the  other  six  subi^tems  together. 

Figure  IS  describes  sone  of  the  major  processes  and  infinmation  crmtained  within  the  STEP 
Pi^uf^km  Cell 


3.  Product  Data  Exdiange  Network  Int^ration 

The  Product  Data  Exchange  Netwok  will  be  a  network  of  organizations  and  individuals  dedicated 
to  suf^pot  the  specification,  validation,  prototyping,  conmerdal  devdc^ment,  and  conversion  to 
STEP.  The  Network  will  hdp  aooderate  the  realizatioi  STEP  and  help  ensure  that  STEP 
wiD  fimctioi  as  intended  in  actual  manufacturing  environments  [47]. 

The  Network  wfll  amsist  of  a  broad  spectrum  of  manuEscturing  facilities  and  research  centos  firon 
industry,  academia,  and  govenunent  linked  electronically  via  oonputCT  networics.  The  plan  is  to 
begin  the  AMRF-based  eqierieooe  in  mechanical  parts,  thra  to  expand  into  otl^  areas. 
Eventual^,  the  Netwi^  wfll  include  sites  in  various  manufacturing  domains,  such  as  aerospace, 
sh^uilding,  apparel,  sheet  metal  products,  electrical  products,  and  others.  A  goal  of  the  Pr^uct 
Data  Exchange  Netwink  is  to  acceknate  the  transition  o[  these  Esdlities  to  STEP-based  infiormation 
systmns. 

The  Natkmal  PDES  Testbed  will  serve  as  headquarters  for  the  Product  Data  Exchange  Network. 
Because  the  Network  and  the  CALS  Test  Network  sponsored  by  the  U.S.  Department  ctf  Defense 
have  similar  objectives,  the  activities  and  results  of  there  two  programs  will  enhance  and  complement 
each  other. 

Several  of  the  netwcvk  sites  will  serve  as  model  facilities  few  developing  STEP-based  manufacturing 
systems.  Various  Product  Data  Exchange  Network  sites  will  perfiewm  STEPvalidatioo  activities  based 
upcm  ^redfic  capabilities  availabie  at  that  site.  There  activities  may  indude  testing  or  developing 
STEP-based  serftware  applications,  developii^  traiaition  plans  to  implement  STEP  in  manu&ctming 
enviremments,  or  producing  actual  products  using  STEP.  Hgure  16  depicts  some  of  the  activities 
which  may  occur  at  Netwo^  sites. 


4.  Omfiguration  Management 

The  National  PDES  Testbed  provides  configuration  management  systems  ami  services  for  key 
cwganizatkms  partidpating  in  major  PDES  and  STEP  activities.  The  Testbed  configuration 
raanagonait  systmn  can  be  toed  to  control  access  aixl  distribution  of  documents  and  software.  In 
the  future,  product  models  and  graphical  representations  will  be  included  [48].  The  functional 
ardiitecture  of  the  intern  is  shown  in  Figure  17. 
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R|.  IS.  The  prcxeaMt  and  infonnaticm  within  the  STEP  Piodiictk»  Cell  of  the  National  PDES  Testbed  wifl  hdlp  ¥enfy 
the  workability  ol  the  standard  in  a  prototype  oiaoiifactunng  envmmnieaL 
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Fig.  17.  The  Testbed  configuration  management  system  will  provide  oonvenimit  access  to  STEP-ielated  doa 
software  for  partidpanls  in  ISO,  the  IGE^DES  Organization,  and  PDES,  Inc.,  as  well  as  the  Nats 
Testbed  (NPT). 


Tbe  cc»e  of  the  ocaifiguratioa  man^ement  system  is  based  upon  a  general  set  of  common 
requirements.  Cushmiused  interfoces  will  be  ojostructed  wfakh  accormt  for  each  organization’s 
mtemal  processes  and  procedures. 


F.  Urn  EatCTsiwi  ef  an  Enteqmbe  Inlegnrtkm  Fnunewoifc 

Concurrent  o^ineering  is  an  en^neering  approach  that  can  help  optimize  the  operations  of  a 
manufscturmg  miterprise.  However,  the  optimizatkm  is  "localized*  to  the  life  cycle-design  to 
productkm  to  suppok-of  the  enterproe’s  product  Clearfy,  concurrent  engiimaing  is  but  one 
dimenskm  of  a  biggm:  idea.  That  bigger  id^  is  the  optmUzation  of  oB  the  enterprise's  opmttions, 
in^idir^  planning  marketing  and  finandal  t^emticns,  as  weB  as  its  transactums  with  its  sup^iers, 
distributors,  and  other  business  partners.  *Multi<nterprise  concurrent  engineering*  is  tlm  term  that 
connotes  the  broacter  optimizatiott.  This  broader  optimization  is  based  upon  tbe  integration  ctf  all 
the  operations  within  an  enterprise  and  between  an  enterpr^  and  its  business  partimrs. 

The  term  fen*  the  standard  architecture  that  would  allow  tbe  integration  of  all  activities  of 
manufacturing  enterprises  is  "enterprise  int^ration  framewc^"  Just  as  STEP  implks  a  standard 
means  of  rqiresenti^  informatkHi  about  a  product  as  weB  as  the  infrastructure  necessary  to  access 
and  ocmtribute  to  that  infewmation  in  a  heterogeneous  computer  environment. 

Enterprise  Integradon  Framework  includes  tlm  structure,  methodolc>gk»,  and  standards  to 
accomplish  the  integration  of  aU  activities  of  an  enterprfre. 

Tbe  key  is  the  sharing  of  all  kinds  of  information  that  allows  for  a  cemeurrent  approach  not  only  to 
engineering,  but  also  to  accounting,  marketing,  mam^ment,  inventory  control,  payroll,  and  other 
activities  that  are  vital  to  the  functioning  of  an  enterprise.  Multi-enterprise  concurrent  engiimering 
through  an  enterprise  integration  framework  is  an  approach  that  can  both  guide  the  integration  of  an 
enterprise’s  activities  and  provide  the  standardized  organization  and  arrangement  for  the  integration 
to  occur. 

Just  as  in  tbe  implementation  of  computer  integrated  rnanufiumiring  (GM)  [49],  the  major  technical 
chaltenge  to  an  mitaptise  integrated  framework  is  the  design  of  the  integrated  ^tem  architecture. 
B^innittg  with  a  ^st^  architecture,  developing  the  methods  to  budd  the  model^  and  then  building 
an  intefpated  framework  is  the  "top  down"  approach  to  Urn  integration  of  all  components  of  an 
entmprise.  A  number  of  ardiitectvres  have  bm  proposed  for  CIM  [50],  but  enterprise  integration 
ardbitectures  have  been  studied  only  recently. 

Because  every  compaiy  is  unique  in  the  way  that  it  operates  ami  because  there  are  different  laws 
and  cultures  in  different  countrws  that  affect  how  businesses  operate,  it  is  essential  that  an  enterprise 
integratk>n  bamewotk  be  flexible  and  conceptually  broad.  Hds  is  tbe  realm  of  enterprise  modeling. 
[51] 

Enterprise  modeling  is  the  abstract  representation,  description  and  definition  of  the  structure, 
processes,  infmmation,  and  resources  of  an  identifiable  business,  government  activity,  or  other  large 
entity.  'Ibe  goal  of  enterprise  modeling  is  to  achieve  model-driven  enterprise  integration  and 
op«atioa.  Abo  important  are  modeling  techniques  for  describing  the  logistic  supply  chains  in  an 
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indwtiy,  induding  the  business  processes  that  occur  among  indepeiKient  but  dosety  cooperating 
enterprkes. 

It  a  also  essential  that  such  a  large  undertaking  as  enterprise  intention  framework  development 
be  carried  out  international^.  Tte  consensus  development  of  international  standards  for  integrating 
enterprises  will  help  assure  that  the  benefits  of  comnirrent  engineering  approaches,  as  well  as 
oppmtunities  f(»r  gl^al  economic  competitiveness,  are  available  to  all  enterprises. 

Open  ^tems  Architecture  (OSA)  b  the  desoiption  of  those  computing  and  networking  systems  that 
are  bas^  on  intKnationai  a^  de  facto  public  domain  standards,  rather  than  the  proprietmy  ^tems 
dominating  the  current  business  environment  The  concept  is  to  be  able  to  create  modular 
information  technology  components,  thus  providing  for  a  "plug  and  play*  ability  to  swap  out  both 
hardware  and  software  components  among  various  vendor  products.  Complex  products  for  OSA 
require  substantial  investment  and  development  time.  Much  of  the  OSA  pixxluct  planning  is 
precompetitive  aiKl  linked  to  standards  activities  that  require  coordination. 

In  the  U.S.,  a  number  of  government  agendes  are  initiating  efforts  to  define  and  develop  an 
enterprise  integration  framework.  These  agencks  include  the  Air  Force  (through  the  Wright 
Reseaidi  and  Development  Center’s  Manufacturing  Technology  Directorate),  the  Defense  Advanced 
Research  Prefects  Agenqr  (DARPA),  the  CALS  office  under  the  Office  of  tite  Secretary  of  Defense, 
and  NIST.  A  major  goal  is  a  set  of  intematiooal  standards  that  provkle  a  framework  upon  which 
commercial  (and  government  funded)  information  technology  related  products  could  be  produced 
that  will  support  multi-entoprise  information  systems  for  iralustrial  applications. 

The  Air  Force  Enterprise  Integration  Framework  Program  is  intended  to  provide  a  common 
reference  model  for  establishing  research  priorities,  harmonizing  standarrhi  devefopment  efforts,  ami 
developing  a  strategy  for  coordinated  investment  by  govenunent  and  industry  in  automated 
infrastructures.  It  is  anticipated  that  an  international  consensus  can  be  built  for  use  of  this 
framework  as  the  modd  for  the  development  or  implmnentation  of  international  standards  and  for 
integrating  mar^  types  applkatkms  and  industries.  The  program  is  part  of  the  U.S.  effort  to 
cooperate  intemationaUy  in  a  coordinated  program  to  defin^  develop,  ami  validate  a  conceptual 
framework  for  inter-  ^  intra-enterprise  integration  based  on  open  systems  principles  and 
international  standards. 

Within  tlte  European  Strategic  Program  for  Research  on  Information  Technology  (ESPRIT),  a 
government-industry  European  CIM  Architecture  (AMICE)  consortium  is  working  to  develop  a 
Computer  Integrate  Manufacturing  Open  Systems  Architecture  (CIM  OSA)  [50],  [52]. 

In  a  sense,  just  as  multi-enterprise  concurrent  engineering  is  the  next  step  in  the  evolution  of 
manufacturing,  the  enterprise  integration  framework  is  the  next  step  in  the  evolution  of  engineering 
sUmdatds.  As  indicated  in  Figure  IS,  engineering  education  will  have  to  evolve  also.  Perhaps 
product  data  engineering  will  become  as  important  as  the  traditional  engineering  specialties  were 
in  the  early  part  of  this  century. 

A  vision  of  the  future  manufacturing  environment  is  shown  in  F^^ure  19.  Independent  enterprises 
(grating  as  suppliers,  ^tem  integrators,  merchants  and  customers  are  integrate  by  an  information 
firework  into  an  effective  system.  M^thin  each  of  these  enterprises,  the  various  product-related 
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Fig.  18.  As  the  evolution  of  manufacturing  and  engineering  standards  progresses,  new  engineering  disciplines  are  required. 
"Product  data  engineering*  may  become  the  next  new  engineering  discipline. 
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fuQctioiis  ami  product  life  cycle  stages  are  integrated  through  the  sharing  of  product  data,  although 
each  stage  maintains  its  own  view  of  the  product  Based  upon  standards,  tte  inter-  and  intra¬ 
enterprise  integration  enables  the  practice  of  multi-enterprise  concurrent  (mgineering  [53].  It  is  the 
practke  of  multi-enterprise  concurrent  engineering  through  which  the  characteristics  of  world-class 
products  are  achieved.  These  characteristics  are  short-time-to-market,  low  cost,  high  qualit>,  and 
high  functionality. 


VI.  CONCLUSIONS 

The  primary  aim  of  any  manufacturing  enterprise  is  to  deliver  working  products  to  customers.  To 
this  could  Ik  mlded  timeliness,  cost  effectiveness,  quality,  reliability,  and  other  characteristics  that 
contribute  to  a  competitive  product  and  hence  to  profits.  Nevertheless,  the  bottom  line  is  simply 
woridng  products  in  the  hands  of  satisfied  customers.  Recently  there  has  been  increased  recognition 
that  concurrent  engineering,  engineering  design,  manufacturing  engineering  practices,  and  data 
exchange  and  interface  standards  are  oitmal  to  intematmnal  competitiveness  [54]  [55].  These 
technologms,  based  upon  information  technology  in  general,  are  the  means  for  providing  to 
customers  high  quality  and  reliable  products,  as  well  as  the  support  for  those  products,  in  a  timely 
and  cost-effective  manner. 

Information  technology  will  provide  an  integrated  level  of  automation  based  upon  standards  and 
frameworks.  It  wiU  oeate  a  climate  in  industry  in  which  enterpi^  can  bei^fit  from  cooperation, 
collaboration  and  interdependence,  without  sacrificii^  their  individual  independence,  initiative,  and 
intellectual  property  rights.  Information  technology,  by  enabling  such  approaches  as  concurrent 
engineering,  will  stimulate  the  necessary  standardization  aiMl  provide  the  economies  of  !v:aie  that 
would  not  be  otherwise  provided  without  drastic  dianges  in  the  way  businesses  in  the  U.S.  operate. 

Concurrent  engineering,  based  upon  information  technology,  will  initiate  a  new  industrial  revolution. 
Certainly,  the  bottom  line  would  stiU  be  working  products  in  the  hands  of  customers,  but  future 
products  are  much  more  likely  to  be  of  higher  quality  and  more  reliable,  state-of-the-art  products 
at  prices  that  are  much  lower  than  they  might  have  been  if  concurrent  engineering  were  not  used. 

It  is  instructive  to  reflect  on  the  mechatucal  drawing  aixl  the  way  it  impacted  the  entire 
manufacturing  process  in  its  era.  Prior  to  the  industrial  revolution,  manufacturing  was  defined  by 
a  physical  model  of  a  product  to  be  reproduced.  For  example,  a  worker  would  ensure  that  the 
dimensioos  of  the  product  to  be  product  corresponded  tlm  model  by  using  calipers  to  transfer 
measurements  fiom  one  to  the  other.  Thu  method  reinforced  the  tradition  that  workers 
manufactured  complete  but  specific  product  types  rather  than  generic  components  of  products. 

In  1801,  Gaspard  Mongc  wrote  "La  Geometrie  Descriptive.”  It  was  the  first  treatise  on  modem 
engineering  drawings.  It  described  the  concept  of  projecting  dimensioned  geometric  views  of  an 
object  onto  three  perpendicular  planes.  Since  it  inclwled  size  and  shape  information,  the  mechanical 
drawing  became  an  objective  standard  of  performance  for  workmanship  and  thus  the  need  for  a 
model  was  eliminated. 

The  drawing  enabled  the  practice  of  designing  a  product  with  interchangeable  parts.  A  product 
could  be  produced  by  contractors  who  could  manufacture  different  components  to  be  assembled. 
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This  capability  to  the  fragmenUtkiD  of  the  manufaaurwg  procos  that  adsts  to  this  day. 
Moreover,  in  today’s  induatrial  enterprises,  the  life  cycle  processes  for  a  product  are  ik}  longer  even 
performed  by  the  same  group  of  people.  In  fi«t,  the  processes  are  dairibuied  through  a  tjetwork 
of  factorks. 

The  mechanical  drawing  cotK^pt  has  lasted  for  almost  200  years.  Althauf^  it  is  a  method  fur 
describii^  products,  just  as  the  physical  model  had  been,  the  mechanical  drawing  revolutiomased  the 
manufacturing  process  itself.  The  drawing  became  dm  output  of  the  design  phsoe  of  the  process 
aiKi  the  input  into  the  production  phase.  Drawings  were  converted  into  producikm  process  plans 
which  were  convert»i  into  programs  or  procedures  for  all  the  manufacturing  operat^ns.  Every  step 
of  the  manufacturing  process  has  its  own  view  of  the  product  dau.  These  dissimiiar  views  make  it 
difficult  to  return  to  tte  designer  evaluative  or  corrective  knowledge  about  the  different  processes. 

As  we  move  into  the  twenty-Gnt  century,  new  manufacturing  technologies  arc  needed  to  improve 
productivity  atxl  competitiveness.  In  our  informaiioa  and  computer  age.  compattks  exchange  and 
share  information  across  the  country.  This  capability  is  needed  for  manufacturing  today’s  complex 
products  such  as  automobiles,  airplanes,  ships,  and  buildings. 

Multi-enterprise  concurrent  engineering  will  require  the  ability  to  store  and  retrieve  produa  data  far 
beyond  the  capability  of  the  mechanical  drawing.  The  replac^ent  for  the  medtanical  drawing  that 
will  allow  revolutionary  new  engineering  techrK)lofpes  is  product  data  sharing.  This  new  capability 
will  make  available  to  the  designer  knowledge  about  all  other  processes.  It  will  process  product  data 
through  automated  computer-based  techniques  that  allow  for  shared  access  among  the  life  cyck 
processes  in  support  of  concurrent  engineering.  It  will  make  available  an  integrated  product  data 
model  that  alk^  access  to  multiple  vkws  of  the  product. 

STEP,  as  well  as  other  new  product  data,  data  exchange  and  interface  standards  and  their  supporting 
technologies,  must  be  impkmented  for  this  new  product  data  sharing  capability  to  be  successful 
That  is  why  cemeurrent  engmeering  is  impost^  te  without  standards. 

The  critical  concept  is  this:  standards  for  product  data  and  data  exchange  are  important  because 
they  enable  and  facilitate  an  automated  form  of  concurrent  enpneering  that  can  be  impiemeoted 
in  a  computerized  environment  This  automated,  or  computer-akled,  concurrent  engineering 
provkies  a  mechanism  for  multi-enterprise  integration.  As  a  result  the  automated  praaice  of 
concurrent  engineering  among  manu&cturing  enterprises,  their  customers  and  tlHsir  suppliers, 
including  suppliers  of  technology  as  well  as  materials  aiKi  compotwnts,  would  create  a  new  kiiKf  of 
multi-enterprise  concurrent  engineering.  This  kind  of  multi-enterprise  (x>ncunrent  engitmeriog  could 
be  achieved  without  the  surrendering  of  historical  forms  of  personal  interactions  currently  praetked 
by  workers  and  managers. 

Accordingly,  an  automated  approach  to  multi-enterprise  concurrent  engineering  could  be  especially 
valuable  in  the  commercial  environment  of  the  U.S.  It  could  merge  the  many  dynamic  and 
innovative,  mostly  small,  entrepreneurial  companies  along  with  larger  manufacturing  enterprises  into 
an  integrated  and  cooperative  group 

Yet  although  they  would  be  integrated  in  tlm  way  they  contribute  their  talents  to  the  life  cycles  of 
products,  participants  in  stu:h  diverse  groups  could  remain  individualistic  and  independent  in  the  way 
tfwy  operate  and  manage  tlmir  businesses.  Although  participating  companies  would  work  in  an 
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integrated  fashion,  and  enjoy  the  beneGts  of  concurrent  engineering,  their  ability  to  retain  their 
individual  Greedoms  would  preserve  for  tiKnt  the  beneGu  assodated  with  the  traditional  strengths 
of  U.S.  commercial  and  individual  diversity. 

In  these  ways,  mulG-enterpiise  comninent  engineering  could  match  the  historically  suaxssful  style 
of  entrepreneurial  innovation  in  the  U.S.  with  the  ccmipetitive  and  economk  elands  of  today’s 
global  economy.  The  result  could  be  the  reemerfcnce  trf  U.S.  manufacturing  in  world  marlKts. 
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Concurrant  Engineering  Through  Product  Data  Standards 


Gary  P.  Carver.  Howard  M.  Bloon 


Concurrent  engineering  invoivee  the  integration  of  people,  systems  arxi  information  foto  a  responsive,  efRcient 
system.  Integration  of  computerized  systems  alows  addtttonai  benefits;  automatic  knoviledge  capture  during 
devefopment  and  ifetime  management  of  a  product  and  automatic  exchange  of  that  knowledge  among  different 
computer  systems.  Critical  enitolers  are  product  data  stnidards  and  enterprise  integration  frameworks.  A 
pioneerfog  assault  on  complex  technical  chalenges  is  assodatod  with  the  emerging  international  Standard  for 
The  Exchange  of  Product  Model  Data  (STEP).  Surpassing  in  scope  previous  standards  efforts,  the  goal  s 
complete,  unambiguoi«,  computer-readable  definition  of  physical  and  function^  characteristics  of  a  product 
througfKXit  its  fife  cycle.  US.  governmerrt,  Industrial,  and  startdards  organizations  are  cooperating  in  a  program. 
Product  Data  Exch^e  using  STEP  (POES),  to  develop  and  implement  STEP  in  a  shared-database  ^rvironment 
POES  wifi  lead  to  higher,  irttegrated  levels  of  automation  based  upon  information  standards  «k1  frameworks. 
US.  manufacturers  wil  benefit  from  concurrent  engineerfog  without  sacrificing  strengths  and  traditions  of 
vKlividuaiity,  initiative,  and  intefiectuaf  property  rights.  C^'ieurrent  engineerfrig,  through  information  technology 
and  standards,  represents  the  power  of  a  new  industriai  revokitioa  The  role  of  the  NIST  National  POES  Testbed, 
technical  leadership  and  testing-based  foundation  for  the  devetopmerrt  of  STEP,  is  descrfoed. 


autofluitad  lumufacturlngj  eoacurrant  daalgn:  concurrent  engineering;  Information  standards; 
Information  standards;  manufacturing  standards;  FDES;  product  data  engineering;  product 
data  sharing:  product  data  standards;  STEP 
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